[pull] main from geoserver:main

.github/workflows/assembly.yml

@@ -40,12 +40,9 @@ jobs:
     - name: Package GeoServer modules and extensions
       run: |
         mvn -B -ntp -nsu -N -f src/pom.xml assembly:single
-    - name: Build community modules without tests
+    - name: Build and package community modules (without tests)
       run: |
-        mvn -B -ntp -U -T3 -DskipTests -PcommunityRelease -f src/community/pom.xml install
-    - name: Package community modules
-      run:  |
-        mvn -B -ntp -nsu -N -f src/community/pom.xml assembly:single
+        mvn -B -ntp -U -T3 -DskipTests -PcommunityRelease,assembly -f src/community/pom.xml install
     - name: Remove SNAPSHOT jars from repository
       run: |
         find ~/.m2/repository -name "*SNAPSHOT*" -type d | xargs rm -rf {}

data/release/demo/WCS_getCoverage.xml

@@ -33,6 +33,6 @@
   </rangeSubset>
   <output>
       <crs>EPSG:32633</crs>
-      <format>GeoTIFF</format>
+      <format>image/png</format>
   </output>
 </GetCoverage>

doc/en/user/source/community/cog/cog.rst

@@ -13,7 +13,18 @@ As a community module, the package needs to be downloaded from the `nightly buil
 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.
+The module is provided as four different packages, depending on the connection type:
+
+* ``cog-http`` for HTTP connections without a particular cloud target
+* ``cog-aws`` for AWS S3 connections
+* ``cog-google`` for Google Cloud Storage connections
+* ``cog-azure`` for Azure Blob Storage connections
+
+To install the module, download the package you need, unpack the zip file contents into the GeoServer ``WEB-INF/lib`` directory and restart GeoServer.
+
+.. warning::
+
+   The dependencies of the various cloud providers might interfere with each other, so please never install together the AWS, Google and Azure modules.
 
 COG GeoTIFF Configuration Panel
 -------------------------------

doc/en/user/source/configuration/demos/index.rst

@@ -39,25 +39,37 @@ Both :ref:`wfs` as well as :ref:`wcs` requests will display the request URL and
 
 .. figure:: img/demos_requests_WFS.png
 
-   WFS 1.1 DescribeFeatureType sample request
+   WFS 1.1 DescribeFeatureType sample request (Demo Request :guilabel:`WFS_describeFeatureType-1.1.xml`)
 
-Click :guilabel:`Submit` to send the request to GeoServer. For WFS and WCS requests, GeoServer will automatically generate an XML response.
+Click :guilabel:`Show Result` or :guilabel:`Show Result in New Page` to send the request to GeoServer. For WFS and WCS requests, GeoServer will automatically generate an XML response.
+
+:guilabel:`Show Result` will show GeoServer's response - both the response headers and the XML/image result - below the  :guilabel:`Show Result` button.  
+If GeoServer's response is XML and you have ticked :guilabel:`Pretty Print XML`, GeoServer's response will be shown with an easy to read styled formatting.
+
+:guilabel:`Show Result in New Page` will show GeoServer's result in a new page (your browser will render the result).
 
 .. figure:: img/demos_requests_schema.png
 
-   XML response from a WFS 1.1 DescribeFeatureType sample request
+   Headers and XML response from a WFS 1.1 DescribeFeatureType sample request after pressing :guilabel:`Show Result`. (Demo Request :guilabel:`WFS_describeFeatureType-1.1.xml`)
 
 Submitting a WMS GetMap request displays an image based on the provided geographic data. 
 
 .. figure:: img/demos_requests_WMS_map.png
 
-   OpenLayers WMS GetMap request
+   Headers and image response for a WMS GetMap request after pressing :guilabel:`Show Result`. (Demo Request :guilabel:`WMS_getMap_multilayer.url`)
 
-WMS GetFeatureInfo requests retrieve information regarding a particular feature on the map image.
+WMS GetFeatureInfo requests retrieve information regarding a particular feature on the map image. 
 
 .. figure:: img/demos_requests_WMS_feature.png
 
-   WMS GetFeatureInfo request
+   Plain text WMS GetFeatureInfo request after pressing :guilabel:`Show Result`.  (Demo Request :guilabel:`WMS_featureInfo.url`)
+
+.. figure:: img/demos_requests_transaction.png
+
+   WFS Transaction result after pressing :guilabel:`Show Result in New Page` (Your browser may render this differently).  (Demo Request :guilabel:`WFS_transactionInsert.xml`) 
+
+
+
 
 .. _srs_list:
 

doc/en/user/source/data/webadmin/layers.rst

@@ -66,7 +66,7 @@ The actions display an :ref:`Edit Layer <data_webadmin_layers_edit_data>` page t
 Remove a Layer
 --------------
 
-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.
+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.
 
 .. figure:: img/data_layers_delete.png
 
@@ -113,15 +113,15 @@ The metadata information will appear in the capabilities documents which refer t
 Coordinate Reference Systems
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-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.
+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.
 
 .. figure:: img/data_layers_CRS.png
 
    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:
+* **SRS Handling**—Determines how GeoServer should handle projection when the two SRSs 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
@@ -131,15 +131,15 @@ A coordinate reference system (CRS) defines how georeferenced spatial data relat
     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
+    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
     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
+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.
 
 .. figure:: img/cascade_srs.png
 
@@ -257,7 +257,7 @@ 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).
+By default this behavior 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.
 
 .. figure:: img/data_layers_root_in_capabilities.png
@@ -342,8 +342,8 @@ WCS Settings
 
 * **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.
 * **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? <http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=94554>`_ for more information.
+* **Formats**—Lists which output formats a layer supports.
+* **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.
 
 KML Format Settings
 ^^^^^^^^^^^^^^^^^^^
@@ -381,14 +381,14 @@ For each enabled dimension the following configuration options are available:
   * **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**—Tries to use the given reference value as-is, regardless of whether it's actually available in the data or not.
 
-* **Reference value**—The default value specifier. Only shown for the default value strategies where its used.
+* **Reference value**—The default value specifier. Only shown for the default value strategies where it's 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,
+  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,
   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.
@@ -406,7 +406,7 @@ For time dimension the value must be in ISO 8601 DateTime format ``yyyy-MM-ddThh
 
 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.
+is copied verbatim into the capabilities document, and as a result, not all clients might recognize that syntax.
 
 .. note:: For more information on specifying times, please see the section on :ref:`wms_time`.
 
@@ -429,9 +429,9 @@ For each enabled dimension the following configuration options are available:
   * **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**—Tries to use the given reference value as-is, regardless of whether it's actually available in the data or not.
 
-* **Reference value**—The default value specifier. Only shown for the default value strategies where its used.
+* **Reference value**—The default value specifier. Only shown for the default value strategies where it's 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

doc/en/user/source/extensions/mapml/index.rst

@@ -286,7 +286,7 @@ The link is generated so that it always work, if the CRS configured for the laye
 
 **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``.   
+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 to the format set with the Default Mime Type dropdown under MapML Settings in the Publishing tab of the Edit Layer settings page.   
 
 Example::
 

doc/en/user/source/gettingstarted/group-quickstart/index.rst

@@ -81,7 +81,7 @@ Create a layer group
 
 #. Locate the :guilabel:`Coordiante Reference Systems` and press :guilabel:`Generate Bounds`.
 
-   Now that layers are listed we they can be used to determine the corodinate reference system and bounds of the layer group.
+   Now that layers are listed we they can be used to determine the coordinate reference system and bounds of the layer group.
 
    .. figure:: images/layers_crs.png 
 

doc/en/user/source/security/tutorials/activedirectory/index.rst

@@ -97,9 +97,9 @@ from the LDAP repository and allow access rights to be assigned to those roles.
 #. Click the ``Users,Group,Roles`` link located under the ``Security`` section 
    of the navigation sidebar.
 
-#. Click the ``Add new link`` under the  ``Role Services`` section.
+#. Click the ``Add new`` link under the ``Role Services`` section.
 
-#. Click the ``LDAP`` option under the  ``New Role Service`` section.
+#. Click the ``LDAP`` option under the ``New Role Service`` section.
 
    .. figure:: images/ldap14.jpg
       :align: center
@@ -134,4 +134,4 @@ Then we need to a choose a user to authenticate on the server (many LDAP server
 
 #. 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.
+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.

doc/en/user/source/services/wcs/requestbuilder.rst

@@ -67,12 +67,19 @@ Once selected, the remainder of the form will be displayed. The following option
 
 There is also a link for :guilabel:`Describe coverage` next to the :guilabel:`Coverage name` which will execute a :ref:`WCS DescribeCoverage <wcs_describecoverage>` request for the particular layer.
 
-At the bottom of the form are two buttons for form submission:
+At the bottom of the form are three buttons for form submission:
 
-* :guilabel:`Get Coverage`—Executes a GetCoverage request using the parameters in the form. This will usually result in a file which can be downloaded.
+* :guilabel:`Get Coverage in Demo Requests`—Opens the :ref:`demos_demorequests` page with the URL and XML Request filled out.
 
-* :guilabel:`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.
+* :guilabel:`Get Coverage in New Page`—Executes a GetCoverage request using the parameters in the form. This will usually result in a file which can be displayed or downloaded.
 
+* :guilabel:`Generate GetCoverage XML`—Generates the GetCoverage XML request using the parameters in the form and then, instead of executing it, outputs the request itself to the screen.
+
+.. figure:: img/wcsrequestbuilder_demo.png
+
+   Get Coverage request in Demo Requests
+
 .. figure:: img/wcsrequestbuilder_xml.png
 
    WCS request builder showing GetCoverage XML
+