-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Supporting TCRS configuration through gridset selector #375
Conversation
The dependency `AWS SDK` of the `cog-s3` plugin requires additional libraries after it was upgraded from version 2.24.13 to 2.27.23. This fixes the issue discussed in https://discourse.osgeo.org/t/missing-jars-for-cog-s3-plugin-in-assembly-xml/110332
Code depends on this GeoTools PR adding PROJ formatting support: geosolutions-it/geotools#84 MapML XML/XSD has been updated to modify the projection elements. Side Question on the next task related to Projection support: The generated LayerPreview will use that CRS. Is it what is requested? |
That is ok! One thing I don't want to have happen is to allow the projection name string to contain
You are correct.
This is done, thanks! |
This is already addressed, there is also a note in the GridSet to TCRS Selector documentation that reports that: Quoting: |
…og-s3-plugin Add missing JARs to assembly.xml file for cog-s3 plugin
…ver#7984) Bumps [org.springframework.security:spring-security-web](https://github.com/spring-projects/spring-security) from 5.8.14 to 5.8.15. - [Release notes](https://github.com/spring-projects/spring-security/releases) - [Changelog](https://github.com/spring-projects/spring-security/blob/main/RELEASE.adoc) - [Commits](spring-projects/spring-security@5.8.14...5.8.15) --- updated-dependencies: - dependency-name: org.springframework.security:spring-security-web dependency-type: direct:production ... Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall looks good, see comments below
src/extension/mapml/src/main/java/org/geoserver/mapml/gwc/gridset/MapMLGridsets.java
Outdated
Show resolved
Hide resolved
src/extension/mapml/src/main/java/org/geoserver/mapml/gwc/gridset/MapMLGridsets.java
Outdated
Show resolved
Hide resolved
src/extension/mapml/src/main/java/org/geoserver/mapml/tcrs/TiledCRSListInitializer.java
Outdated
Show resolved
Hide resolved
src/extension/mapml/src/main/java/org/geoserver/mapml/tcrs/TiledCRSListInitializer.java
Outdated
Show resolved
Hide resolved
src/extension/mapml/src/main/java/org/geoserver/mapml/tcrs/TiledCRSListInitializer.java
Outdated
Show resolved
Hide resolved
src/extension/mapml/src/main/java/org/geoserver/mapml/tcrs/TiledCRSConstants.java
Outdated
Show resolved
Hide resolved
src/extension/mapml/src/main/java/org/geoserver/mapml/web/MapMLTCRSSettingsPage.java
Show resolved
Hide resolved
src/extension/mapml/src/main/java/org/geoserver/mapml/MapMLFeatureUtil.java
Outdated
Show resolved
Hide resolved
src/extension/mapml/src/main/java/org/geoserver/mapml/MapMLFeatureUtil.java
Outdated
Show resolved
Hide resolved
|
||
@Test | ||
public void testGridsetToTiledCRS() throws Exception { | ||
CoordinateReferenceSystem crs = CRS.decode("MapML:UTM31WGS84Quad"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good. I would also check that:
- The code shows up in "CRS.getSupportedCodes()
- A GUI test that adds a built-in valid griset as a valid TRCS, and after the submission, the CRS class can find it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tests Added.
The docuemntation was restructured to seperate out administrator from worksapce administrator in response to security vulnerability on log file traversal.
geoserver#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
…version_from_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`
e4e8124
to
c72f0f7
Compare
@aaime. |
Go for the official repo! |
c72f0f7
to
3758e34
Compare
`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
c239c1d
to
b7cfb49
Compare
b7cfb49
to
1d794f1
Compare
@prushforth fix for axis order merged here: geoserver#8143 |
Checklist
main
branch (backports managed later; ignore for branch specific issues).For core and extension modules:
[GEOS-XYZWV] Title of the Jira ticket
.