[pull] main from geoserver:main #40
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
The docuemntation was restructured to seperate out administrator from worksapce administrator in response to security vulnerability on log file traversal.
#7961) fall back to using the URL of the capabilities document itself. Update MapMLBaseProxyTest.java to check the cascaded request against the request URL from the capabilities document OR if that is null, use the URL OF the capabilities document as the base. Update assertCascading in MapMLWMTSProxyTest.java to compare against resource request URL from capabilities document OR if that is null, use the URL OF the capabilities document as the base.
…ment section
* Centralize the declaration of geotools dependencies to the root pom's
dependencyManagement and remove `<version>${gt.version}</version>` in
module poms for consistency.
* Exclude `xml-apis` and apache `fop` in the root pom dependency management section
Of especial interes for the `gt-app-schema` module not to carry over the
unnecessary (sice Java 1.6) `xml-apis` jar, whose presence also makes the
eclipse IDE complain there are multiple sources for classes
in the `javax.xml.namespace`, `org.w3c.dom`, and other packages.
commit 397981a4e9dc310219270f82b2e560f6d3de4127
Author: Gabriel Roldan <[email protected]>
Date: Tue Aug 6 12:05:38 2024 -0300
…rom_root_pom Declare all GeoTools dependencies in the root pom's dependency management section
The way it is stated now is misleading, because the LEGEND_OPTIONS params are required, but they are mentioned after the optional parameters.
Add a data directory under build/cite/ogcapi-features10. This is an extract of the [release](../../../data/release/) data directory without the raster layers and their corresponding datasets, for the purpose of executing the ogcapi-features-1.0 conformance test suite against this well known datasets. Note although it adds the shapefiles and geopackage again, they won't incur in any size overhead for the repository given the way git stores files.
This commit adds support for running CITE (Compliance & Interoperability Testing Evaluation) tests for `OGC API - Features 1.0`. It includes updates to dependencies, configuration changes, a new CI workflow, and test data handling to ensure proper validation of GeoServer¿s conformance. * The new `ogcapi-features10` test suite runs against the latest version of the [ogccite/ets-ogcapi-features10:1.7.1-teamengine-5.4.1](https://hub.docker.com/r/ogccite/ets-ogcapi-features10/tags) "TEAM Engine and OGC API - Features test suite", using the TeamEngine¿s REST API. Refer to the "Using the REST API" section in the [User Guide](https://opengeospatial.github.io/teamengine/users.html) for more details. * Introduced a new GitHub Actions workflow that builds and runs the CITE tests. * The CITE tests run against all feature types present in the `release` data directory. * Configured the WFS to declare `EPSG:4326` and `EPSG:3857` for all FeatureTypes, ensuring that tests do not attempt reprojection between incompatible coordinate systems or boundaries. * Disabled the `tiger:giant_polygon` FeatureType as the test suite tries to reproject it to CRSs that can't cover its single world-wide polygon. * Updated the CITE build and run scripts located in `build/cite/` to ensure they can be executed. * The existing CITE tests continue to run via CLI commands against the `geoserver-docker.osgeo.org/geoserver-cite:teamengine_latest` image. to include only the necessary dependencies for this specific test suite. * Updated the `geoserver.war` file used for testing to default to the locally built version. A `make war` target has been introduced. * Added an `ogcapi-features` Maven profile in `src/web/app/pom.xml`
`EPSG:4087` (WGS 84 / World Equidistant Cylindrical) is a global projection, while `EPSG:3857` (WGS 84 / Pseudo-Mercator) is not. Since the `ogcapi-features-1.0` ETS fails while doing coordinate transformations on itself, despite GeoServer having returned transformed geometries (albeit outside the area of validity of the target CRS), let's use two default published CRS's that cover the whole globe. Re-enable the `tiger:giant_polygon` layer, since now it can be reprojected across the declared global CRS's.
…imitations The ets-ogcapi-features10 test suite will chek the transformed collection items fall inside the collection's declared spatialExtent (WGS84). In doing so, the test themselves are limited to 7 decimals for geographic coordinates, and hence will fail with GeoServer's higher accuracy, despite GeoServer responses being correct.
…nal fixes Use a patched version of `ogccite/ets-ogcapi-features10:1.8-SNAPSHOT-teamengine-5.4.1`. Currently, we require the following pull request to be applied: [Fix global crs codes lookup in discovery collections crs tests](opengeospatial/ets-ogcapi-features10#255) to the test suite. This may happen again, hence we're introducing a build step to generate the required `ogccite/ets-ogcapi-features10` image out of the `geoserver/ets-ogcapi-features10` fork, using a branch named `geoserver/integration`. The procedure to maintain that branch is to rebase on top of the upstream master branch as required, and apply the additional branches with `git merge --no-ff`.
Use a patched ogccite/ets-ogcapi-features10 Docker image with additional fixes
Test ogcapi-features both * Respects the configured number of decimal places when encoding GeoJSON, both in the Collection document bounds and for items coordinates (this last part is performed already by the WFS GeoJSON encoder) * The encoded collection bounds fully covers the items, as asserted by the CITE tests,
… the configured decimal places
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )