layers.rst 30 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462
  1. .. _data_webadmin_layers:
  2. Layers
  3. ======
  4. 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.
  5. 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.
  6. .. figure:: img/data_layers.png
  7. Layers View
  8. Layer types
  9. -----------
  10. 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.
  11. .. list-table::
  12. :widths: 5 70
  13. :header-rows: 1
  14. * - Field
  15. - Description
  16. * - .. image:: img/raster_icon.png
  17. - Raster (grid)
  18. * - .. image:: img/polygon_icon.png
  19. - Polygon
  20. * - .. image:: img/line_string_icon.png
  21. - Line
  22. * - .. image:: img/point_icon.png
  23. - Point
  24. .. _data_webadmin_layers_add_a_layer:
  25. Add a Layer
  26. -----------
  27. At the upper left-hand corner of the layers view page there are two buttons for the adding and removal of layers.
  28. The green plus button allows you to add a new layer. The red minus button allows you to remove selected layers.
  29. .. figure:: img/data_layers_add_remove.png
  30. Buttons to Add and Remove a Layer
  31. Clicking the :guilabel:`Add a new layer` button brings up a :guilabel:`New Layer Chooser` panel. The menu displays all currently enabled stores. From this menu, select the Store where the layer should be added.
  32. .. figure:: img/data_layers_add_chooser.png
  33. List of all currently enabled stores
  34. Upon selection of a Store, a list is displayed of resources within the store.
  35. Resources which have already been published as layers are listed first, followed by other resources which
  36. are available to be published.
  37. In this example, ``giant_polygon``, ``poi``, ``poly_landmarks`` and ``tiger_roads`` are all existing layers within the NYC store.
  38. .. figure:: img/data_layers_add_view.png
  39. List of published and available resources in a store
  40. To add a layer for an available resource click :guilabel:`Publish`.
  41. To add a new layer for a published resource click :guilabel:`Publish Again`.
  42. (Note that when re-publishing the name of the new layer may have to be modified to avoid conflict with an existing layer.)
  43. The actions display an :ref:`Edit Layer <data_webadmin_layers_edit_data>` page to enter the definition of the new layer.
  44. Remove a Layer
  45. --------------
  46. 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 page to the next.
  47. .. figure:: img/data_layers_delete.png
  48. Some layers selected for removal
  49. All layers can be selected for removal by clicking the checkbox in the header.
  50. .. figure:: img/data_layers_delete_all.png
  51. All layers selected for removal
  52. Once layer(s) are selected, the :guilabel:`Remove selected resources` link is activated. Once you've clicked the link, you will be asked to confirm or cancel the removal. Selecting :guilabel:`OK` removes the selected layer(s).
  53. .. _data_webadmin_layers_edit_data:
  54. Edit Layer: Data
  55. ----------------
  56. To view or edit a layer, click the layer name. A layer configuration page will be displayed. The :guilabel:`Data` tab, activated by default, allows you to define and change data parameters for a layer.
  57. .. figure:: img/data_layers_edit_data.png
  58. Edit Layer: Data tab
  59. Basic Info
  60. ^^^^^^^^^^
  61. The beginning sections—Basic Resource Info, Keywords and Metadata link—are analogous to the :ref:`service_metadata` section for WCS, WFS, and WMS.
  62. These sections provide "data about the data," specifically textual information that make the layer data easier to understand and work with.
  63. The metadata information will appear in the capabilities documents which refer to the layer.
  64. * **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.)
  65. * **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)
  66. * **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.
  67. * **Title**—Human-readable description to briefly identify the layer to clients (required)
  68. * **Abstract**—Describes the layer in detail
  69. * **Keywords**—List of short words associated with the layer to assist catalog searching
  70. * **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.
  71. .. figure:: img/data_layers_meta.png
  72. Adding a metadata link in FGDC format
  73. Coordinate Reference Systems
  74. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  75. A coordinate reference system (CRS) defines how georeferenced spatial data relates to real locations on the Earth’s surface. CRSs 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.
  76. .. figure:: img/data_layers_CRS.png
  77. Coordinate reference system of a layer
  78. * **Native SRS**—Specifies the coordinate system the layer is stored in. Clicking the projection link displays a description of the SRS.
  79. * **Declared SRS**—Specifies the coordinate system GeoServer publishes to clients
  80. * **SRS Handling**—Determines how GeoServer should handle projection when the two SRSs differ. Possible values are:
  81. * **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,
  82. 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
  83. database to find the best transformation steps to other coordinate reference systems should reprojection be required. Use this option when the source has no
  84. 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).
  85. * **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
  86. 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
  87. CRS is requested, the reprojection will go directly from native to declared)
  88. * **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
  89. using the native CRS in all other requests (with no reprojection in between, unless explicitly requested from client). This is particularly problematic if the source
  90. 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).
  91. 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
  92. and datum change.
  93. 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**
  94. only if you really know what you're doing.
  95. For Cascaded WMS and WMTS servers and WFS-NG layers with multiple supported CRSs in the capabilities document, the Native CRS can be selected by clicking the Find button next to the Native SRS field.
  96. .. figure:: img/cascade_srs.png
  97. Bounding Boxes
  98. ^^^^^^^^^^^^^^
  99. The bounding box determines the extent of the data within a layer.
  100. * **Native Bounding Box**—The bounds of the data specified in the Native SRS. These bounds can be generated by clicking the :guilabel:`Compute from data` button or they can be generated from the SRS definition by clicking the :guilabel:`Compute from SRS bounds` button. The SRS used depends on the :guilabel:`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.
  101. * **Lat/Lon Bounding Box**—The bounds specified in geographic coordinates. These bounds can be calculated by clicking the :guilabel:`Compute from native bounds` button.
  102. .. figure:: img/data_layers_BB.png
  103. Bounding Boxes of a layer
  104. Coverage Parameters (Raster)
  105. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  106. 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 :guilabel:`ReadGridGeometry2D.` For ImageMosaic, you can use :guilabel:`InputImageThresholdValue`, :guilabel:`InputTransparentColor`, and :guilabel:`OutputTransparentColor` to control the rendering of the mosaic in terms of thresholding and transparency.
  107. Curves support (Vector)
  108. ^^^^^^^^^^^^^^^^^^^^^^^
  109. GeoServer can handle geometries containing circular arcs (initially only from Oracle Spatial and the "properties data store", though more data sources are planned).
  110. 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.
  111. There are two options pertaining the circular arcs:
  112. * **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.
  113. * **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").
  114. .. figure:: img/curved.png
  115. Curved geometry control
  116. .. _data_webadmin_layers_edit_publishing:
  117. Feature Type Details (Vector)
  118. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  119. Vector layers have a list of the :guilabel:`Feature Type Details`. These include the :guilabel:`Property` and :guilabel:`Type` of a data source. For example, the ``sf:archsites`` layer shown below includes a geometry (``the_geom``) of type "point".
  120. .. figure:: img/data_layers_feature.png
  121. Feature Type Details
  122. The :guilabel:`Nillable` option refers to whether the property requires a value or may be flagged as being null. Meanwhile :guilabel:`Min/Max Occurrences` refers to how many values a field is allowed to have. Currently both :guilabel:`Nillable` and :guilabel:`Min/Max Occurrences` are set to ``true`` and ``0/1`` but may be extended with future work on complex features.
  123. The :guilabel:`Customize attributes` checkbox opens an attribute editor allowing customization.
  124. .. figure:: img/data_layers_feature_customize.png
  125. Attribute customization
  126. It is possible to:
  127. * Change the order of attributes, using either the up/down arrows, or dragging the attribute row.
  128. * Remove an attribute using the "remove" icon at the end of the attribute row.
  129. * Add a new attribute, which will be computed based on the :guilabel:`Source` CQL expression.
  130. * Rename an attribute.
  131. * Add a description of the attribute, which will be visible wherever the feature type is described.
  132. * Change the nillability of the attribute, for example, making the attribute mandatory even if it's
  133. not in the data source, and vice-versa.
  134. * Change the type of the attribute using the `Type` column. The most common types are available in
  135. a drop-down on editing, but it's possible to indicate any valid Java class, as long as GeoServer
  136. has a converter that goes from the value produced by the :guilabel:`Source` expression to the
  137. target type (new converters can be plugged in with some Java programming).
  138. * Reset the table to the native settings, using the :guilabel:`Reset customization` link.
  139. Some of the feature type edits might result in the layer not being editable anymore, for example,
  140. by removing an attribute that is marked as mandatory in the data source.
  141. Restricting features showing up in the layer
  142. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  143. By default GeoServer will publish all the features available in the layer. It is possible
  144. to restrict the features to a subset by specifying a CQL filter in the configuration:
  145. .. figure:: img/data_layers_cql.png
  146. Restrict the features on layer by CQL filter
  147. .. note::
  148. It is recommended to use this setting for layers that are not meant to be edited. The filter
  149. is only applied to reads, if a WFS-T insert adds a feature not matching the filter, it will
  150. be added to the store anyways, but won't show up in any of the outputs.
  151. Edit Layer: Publishing
  152. ----------------------
  153. The Publishing tab configures HTTP and WMS/WFS/WCS settings.
  154. .. figure:: img/data_layers_edit_publish.png
  155. Edit Layer: Publishing tab
  156. HTTP Settings
  157. ^^^^^^^^^^^^^
  158. Cache parameters that apply to the HTTP response from client requests.
  159. * **Response Cache Headers**— If selected, GeoServer will not request the same tile twice within the time specified in :guilabel:`Cache Time`. One hour measured in seconds (3600), is the default value for :guilabel:`Cache Time`.
  160. .. figure:: img/data_http_response_caching_settings.png
  161. Root Layer in Capabilities
  162. ^^^^^^^^^^^^^^^^^^^^^^^^^^
  163. Capabilities documents in GeoServer always have a top level (root) Layer element that works as a container of all the available layers and groups.
  164. When a layer is the only top level element in the Capabilities document, it is possible to remove this root Layer and return
  165. a hierarchy where the layer is the root instead.
  166. To enable this functionality, choose the **No** option from the Root Layer in Capabilities section.
  167. By default this behavior is inherited from the global WMS service settings (**WMS Global Settings** option).
  168. Finally, it is possible to override the service settings and force a **Yes** to always include the GeoServer root element.
  169. .. figure:: img/data_layers_root_in_capabilities.png
  170. Layer root layer in capabilities options
  171. Services Settings
  172. ^^^^^^^^^^^^^^^^^
  173. Sets services configuration on layer level.
  174. .. figure:: img/service_enable_layer.png
  175. Services Settings
  176. * **Selectively enable services for layer**—Activate/deactivate service enable/disable configuration for the layer.
  177. * **Enabled Services**—Selects enabled services list for this layer.
  178. * **Disabled Services**—Selects disabled services list for this layer.
  179. .. note::
  180. 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.
  181. WMS Settings
  182. ^^^^^^^^^^^^
  183. Sets the WMS specific publishing parameters.
  184. .. figure:: img/wms_settings.png
  185. WMS Settings
  186. * **Queryable**—Controls whether the layer is queryable via WMS ``GetFeatureInfo`` requests.
  187. * **Default style**—Style that will be used when the client does not specify a named style in GetMap requests.
  188. * **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.
  189. * **Default rendering buffer**—Default value of the ``buffer`` GetMap/GetFeatureInfo vendor parameter. See the :ref:`wms_vendor_parameters` for more details.
  190. * **Default WMS path**—Location of the layer in the WMS capabilities layer tree. Useful for building non-opaque layer groups
  191. * **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 :ref:`Raster Rendering Options <services_webadmin_wms_raster_options>` for details). Can be overridden by the :ref:`interpolations vendor parameter <wms_vendor_parameter_interpolations>`.
  192. WMS Attribution
  193. ^^^^^^^^^^^^^^^
  194. Sets publishing information about data providers.
  195. .. figure:: img/data_layers_WMS.png
  196. WMS Attribution
  197. * **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.
  198. * **Attribution Link**—URL to the data provider's website.
  199. * **Logo URL**—URL to an image that serves as a logo for the data provider.
  200. * **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 :guilabel:`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.
  201. WFS Settings
  202. ^^^^^^^^^^^^
  203. Sets the WFS specific publishing parameters.
  204. .. figure:: img/wfs_settings.png
  205. WFS Settings
  206. * **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)
  207. * **Maximum number of decimals**—Sets the maximum number of decimals in GML output.
  208. * **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.
  209. .. note::
  210. 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:
  211. .. figure:: img/data_layers_WFS.png
  212. WFS otherSRS/otherCRS override
  213. 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.
  214. * **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.
  215. WCS Settings
  216. ^^^^^^^^^^^^
  217. * **Request SRS**—Provides a list of SRSs the layer can be converted to. :guilabel:`New Request SRS` allows you to add an SRS to that list.
  218. * **Interpolation Methods**—Sets the raster rendering process, if applicable.
  219. * **Formats**—Lists which output formats a layer supports.
  220. * **GeoSearch**—When enabled, allows the Google GeoSearch crawler to index from this particular layer. Obsolete since 2012. See `Google Retired Geo Sitemap Support <https://www.seroundtable.com/geo-sitemaps-gone-14941.html>`_ for more information.
  221. KML Format Settings
  222. ^^^^^^^^^^^^^^^^^^^
  223. Limits features based on certain criteria, otherwise known as **regionation**.
  224. * **Default Regionating Attribute**—Choose which feature should show up more prominently than others.
  225. * **Regionating Methods**—There are four types of regionating methods:
  226. * *external-sorting*—Creates a temporary auxiliary database within GeoServer. The first request to build an index takes longer than subsequent requests.
  227. * *geometry*—Externally sorts by length (if lines) or area (if polygons)
  228. * *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.
  229. * *random*—Uses the existing order of the data and does not sort
  230. .. _data_webadmin_layers_edit_dimensions:
  231. Edit Layer: Dimensions
  232. ----------------------
  233. 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.
  234. These dimensions can be enabled and configured on the Dimensions tab.
  235. .. figure:: img/data_layers_dimension_editor_time.png
  236. TIME dimension enabled for a WMS layer
  237. For each enabled dimension the following configuration options are available:
  238. * **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.
  239. * **End attribute**—Attribute name for picking the end of the value range for this dimension (optional, vector only).
  240. * **Presentation**—The presentation type for the available values in the capabilities document. Either *each value separately (list)*, *interval and resolution*, or *continuous interval*.
  241. * **Default value**—Default value to use for this dimension if none is provided with the request. Select one of from four strategies:
  242. * **smallest domain value**—Uses the smallest available value from the data
  243. * **biggest domain value**—Uses the biggest available value from the data
  244. * **nearest to the reference value**—Selects the data value closest to the given reference value
  245. * **reference value**—Tries to use the given reference value as-is, regardless of whether it's actually available in the data or not.
  246. * **Reference value**—The default value specifier. Only shown for the default value strategies where it's used.
  247. * **Nearest match**—Whether to enable, or not, WMS nearest match support on this dimension. Currently supported only on the time dimension.
  248. * **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.
  249. * **Acceptable interval**—A maximum search distance from the specified value (available only when nearest match is enabled).
  250. Can be empty (no limit), a single value (symmetric search) or using a ``before/after`` syntax to
  251. specify an asymmetric search range. Time distances should be specified using the ISO period syntax. For example, ``PT1H/PT0H`` allows to search up to one hour before the user specified value,
  252. but not after.
  253. * **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``.
  254. * **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.
  255. Has to be either numeric, an ISO 8601 DateTime format or the string ``PRESENT``. If left blank GeoServer will determine the value automatically
  256. based on the data. When using 'PRESENT' the current DateTime of the server will be used when the capabilities document is generated.
  257. Setting this value manually may be desired when working with layers consisting of huge amounts of data where the automatic determination can get slow.
  258. This parameter is only handled for WMS Layers in their capabilities document.
  259. * **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.
  260. Has to be either numeric, an ISO 8601 DateTime format or the string ``PRESENT``. If left blank GeoServer will determine the value automatically
  261. based on the data. When using 'PRESENT' the current DateTime of the server will be used when the capabilities document is generated.
  262. Setting this value manually may be desired when working with layers consisting of huge amounts of data where the automatic determination can get slow.
  263. This parameter is only handled for WMS Layers in their capabilities document.
  264. 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.
  265. Only for the "Reference value" strategy, it is also possible to use ranges or times and ranges of elevation, in the form ``fromValue/toValue``.
  266. 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
  267. is copied verbatim into the capabilities document, and as a result, not all clients might recognize that syntax.
  268. .. note:: For more information on specifying times, please see the section on :ref:`wms_time`.
  269. Vector Custom Dimensions
  270. ^^^^^^^^^^^^^^^^^^^^^^^^
  271. GeoServer also supports adding custom dimensions to vector layers, defining their names and configurations.
  272. .. figure:: img/data_layers_dimension_editor_custom.png
  273. Custom dimension enabled for a vector layer
  274. For each enabled dimension the following configuration options are available:
  275. * **Name**—Custom dimension name.
  276. * **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.
  277. * **End attribute**—Attribute name for picking the end of the value range for this dimension (optional, vector only).
  278. * **Presentation**—The presentation type for the available values in the capabilities document. Either *each value separately (list)*, *interval and resolution*, or *continuous interval*.
  279. * **Default value**—Default value to use for this dimension if none is provided with the request. Select one of from four strategies:
  280. * **smallest domain value**—Uses the smallest available value from the data
  281. * **biggest domain value**—Uses the biggest available value from the data
  282. * **nearest to the reference value**—Selects the data value closest to the given reference value
  283. * **reference value**—Tries to use the given reference value as-is, regardless of whether it's actually available in the data or not.
  284. * **Reference value**—The default value specifier. Only shown for the default value strategies where it's used.
  285. * **Nearest match**—Whether to enable, or not, WMS nearest match support on this dimension.
  286. * **Acceptable interval**—A maximum search distance from the specified value (available only when nearest match is enabled).
  287. Can be empty (no limit), a single value (symmetric search) or using a ``before/after`` syntax to
  288. specify an asymmetric search range.
  289. * **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.
  290. Has to be either numeric, an ISO 8601 DateTime format or the string ``PRESENT``. If left blank GeoServer will determine the value automatically
  291. based on the data. When using 'PRESENT' the current DateTime of the server will be used when the capabilities document is generated.
  292. Setting this value manually may be desired when working with layers consisting of huge amounts of data where the automatic determination can get slow.
  293. This parameter is only handled for WMS Layers in their capabilities document.
  294. * **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.
  295. Has to be either numeric, an ISO 8601 DateTime format or the string ``PRESENT``. If left blank GeoServer will determine the value automatically
  296. based on the data. When using 'PRESENT' the current DateTime of the server will be used when the capabilities document is generated.
  297. Setting this value manually may be desired when working with layers consisting of huge amounts of data where the automatic determination can get slow.
  298. This parameter is only handled for WMS Layers in their capabilities document.
  299. .. _layer_security:
  300. Edit Layer: Security
  301. ^^^^^^^^^^^^^^^^^^^^^^^^
  302. .. note:: For more information on data access rules, please see the section on :ref:`security_webadmin_data`.
  303. Sets data access rules at layer level.
  304. .. figure:: img/data_layers_security_editor.png
  305. To create/edit layer's data access rules simply check/uncheck checkboxes according to desired access mode and role.
  306. The Grant access to any role checkbox grant each role for each access mode.