deegree / deegree-ogcapi Goto Github PK

Describe the bug
The help documentation of a deegree OGC API webapp which is linked in HTML view at the bottom left is not reachable and displays an empty page instead.
The reference implementation can be used to reproduce the bug: http://cite.deegree.org/deegree-ogcapi-1.3/datasets/kitaeinrichtung

To Reproduce
Steps to reproduce the behavior (here example for HTML encoding):

1. Go to http://cite.deegree.org/deegree-ogcapi-1.3/datasets or http://cite.deegree.org/deegree-ogcapi-1.3/datasets/kitaeinrichtung
2. Click on "Help" at the bottom left
3. Documentation is not shown and white site is displayed instead

Expected behavior
Documentation shall be displayed.

Desktop (please complete the following information):

• Version: 1.3
• Datasource: postgres/postgis
• Browser: firefox
• GIS-Client: web browser

Currently the new configuration schema files introduced with deegree OGC API such as features.xsd, datasets.xsd and htmlview.xsd are not published on https://schemas.deegree.org/.

• https://schemas.deegree.org/ogcapi/1.3/* - for all deegree OGC API schema files introduced

Related issues:

• deegree/deegree3#1495

Currently log4j 1.2.17 is used. deegree webservices is using log4j 2.x. :
as defined in https://github.com/deegree/deegree-ogcapi/blob/main/pom.xml#L747

It is required to upgrade the logging provider to log4j 2.x same version as current release version of deegree webserices.

Currently deegree OGC API Features doesn't compile with JDK 11+/17+. The binaries shall be executable on a runtime environment based on OpenJDK 11/17 and Tomcat 9/10.

Using the deegree OGC API demo under http://cite.deegree.org/deegree-ogcapi-1.3/datasets/strassenbaumkataster/collections/strassenbaumkataster/items, it seems that the feature preview map is unavailable.

The GET request URLs:

• https://cdn.jsdelivr.net/gh/openlayers/openlayers.github.io@master/en/v6.1.1/css/ol.css
• https://cdn.jsdelivr.net/gh/openlayers/openlayers.github.io@master/en/v6.1.1/build/ol.js
  both result in a HTTP status code 403.

This is most likely caused by the renaming of the master branch to main in the https://github.com/openlayers/openlayers.github.io repository.

The correct URLs should therefore be:

• https://github.com/openlayers/openlayers.github.io/blob/main/dist/en/v6.1.1/build/ol.js
• https://github.com/openlayers/openlayers.github.io/blob/main/dist/en/v6.1.1/css/ol.css

In this step, the version could potentially upgraded to https://github.com/openlayers/openlayers.github.io/tree/main/dist/en/v6.9.0

Feature Description:

Users can configure links in the collection response document, including href, rel, type and title elements.

User can configure links to:

1. bulk downloads (for example, a geopackage they are hosting)
2. mapping encodings
3. the INSPIRE feature collection library
4. other

Additional information:

EXAMPLE MAPPING ENCODING

Link to description of mapping encoding: Add /rec/geojson/geojson-inspire (which is a recommendation): https://github.com/INSPIRE-MIF/gp-ogc-api-features/blob/master/spec/oapif-inspire-download.md

EXAMPLE FEATURE LIBRARY

Link to featureconcept:
Add /req/pre-defined/feature-concept-dictionary from the INSPIRE requirements here: https://github.com/INSPIRE-MIF/gp-ogc-api-features/blob/master/spec/oapif-inspire-download.md#req-bulk-download

Definition of done:

Links in the collection response document are configurable.

The HTML view fails to show the OL map due to a HTTP 404 error.
The version of OL v6.1.1 used in the demo is not available at https://cdn.jsdelivr.net/gh/openlayers/openlayers.github.io@master/en/ anymore.

Error:
Request URL: https://cdn.jsdelivr.net/gh/openlayers/openlayers.github.io@master/en/v6.1.1/build/ol.js
Request Method: GET
Status Code: 404
Remote Address: 146.75.61.229:443

When a datasource contains data with German Umlaute than these characters are not returned correctly in JSON encoding, e.g. http://cite.deegree.org/deegree-ogcapi-1.3/datasets/strassenbaumkataster/collections/strassenbaumkataster/items?f=json. HTML encoding http://cite.deegree.org/deegree-ogcapi-1.3/datasets/strassenbaumkataster/collections/strassenbaumkataster/items?f=html looks fine.

When using a different CRS than EPSG:25832 the Collections view in HTML shows data not correct on map.

Currently JS libs such as OL are integrated remotely via CDN.
This approach allows tracking of users access to the web app.
The libs shall be packaged with the web app and managed as a dependency.

As described in deegree/deegree3#1637 GeoJSON does not support features with multiple geometries.

Therefor it is currently not possible to provide feature types with multiple geometry properties with deegree OGC API Features.

After merged PR #10 the build for JDK 1.8 is broken.
Build error:

Error Message

org.glassfish.jersey.server.ServerExecutorProvidersConfigurator.registerExecutors(Lorg/glassfish/jersey/internal/inject/InjectionManager;Lorg/glassfish/jersey/model/internal/ComponentBag;Lorg/glassfish/jersey/spi/ExecutorServiceProvider;Lorg/glassfish/jersey/spi/ScheduledExecutorServiceProvider;)V

Stacktrace

java.lang.NoSuchMethodError: org.glassfish.jersey.server.ServerExecutorProvidersConfigurator.registerExecutors(Lorg/glassfish/jersey/internal/inject/InjectionManager;Lorg/glassfish/jersey/model/internal/ComponentBag;Lorg/glassfish/jersey/spi/ExecutorServiceProvider;Lorg/glassfish/jersey/spi/ScheduledExecutorServiceProvider;)V

Standard Output

[02:52:53]  WARN: [GMLSchemaInfoSet] Unhandled particle: MODEL_GROUP
[02:52:53]  WARN: [GMLSchemaInfoSet] Unhandled particle: MODEL_GROUP
[02:52:53]  WARN: [GMLSchemaInfoSet] Unhandled particle: MODEL_GROUP

Standard Error

Feb 17, 2022 2:52:53 AM org.glassfish.jersey.test.inmemory.InMemoryTestContainerFactory$InMemoryTestContainer <init>
INFO: Creating InMemoryTestContainer configured at the base URI http://localhost:9998/

ref: https://buildserver.deegree.org/view/deegree-ogcapi/job/deegree-ogcapi-BUILD/37/

Is your feature request related to a problem? Please describe.
deegree OGCAPI shall implement OGC API - Features - Part 4: Create, Replace, Update and Delete

Describe the solution you'd like
deegree OGC API is providing an implementation of Part 4 - CRUD to replace WFS-T.

Describe alternatives you've considered
none

Additional context
none

Hi,

I am running deegree OGC API in Apache Tomcat 9.0.69 on Windows 10, serving INSPIRE-compliant Planned Land Use data based on this schema in blob mode.

When I navigate to the API definition, in my case: http://localhost:8080/deegree-services-oaf/datasets/geojson_wfs/api, I get a "Failed to load API definition" error.

deegree configuration files:

deegree_api_wfs_configuration(1).zip

Do you have any documentation that explains how I can configure the OAS defintion document?

Kind regards,
Kate

Feature Description:

The OAS 3 root document is available at openapi.json or openapi.yaml, with file extension.

Currently, deegree ogcapi makes it available at XX/api.

Definition of done:

OAS 3 document is available at openapi.json or openapi.yaml as specified in the Dutch API requirements and the Dutch validator.

The functionality is optional.

The current packaging of the webapp of OGC API does not include protection of REST API.

A first draft was done in deegree/deegree3#1180 to include a way of securing the REST API.

References:

• deegree/deegree3#1180

Feature Description:

The URI of the API (base path) is extended to include the major version number, prefixed by the letter v.

A pull request is made so that this feature can be available as an optional extension to the core deegree OGC API product.

Additional information:

This issue is related to the Dutch API requirement labeled AP-20:

API-20: Include the major version number in the URI

The URI of an API (base path) must include the major version number, prefixed by the letter v. This allows the exploration of multiple versions of an API in the browser. The minor and patch version numbers are not part of the URI and may not have any impact on existing client implementations.

An example of a base path for an API with current version 1.0.2:

https://api.example.org/v1/

Definition of done:

The URI of an API (base path) includes the major version number, prefixed by the letter v.

A pull request including the functionality is made available to deegree OGC API.

The functionality is optional.

Currently the deegree ogcapi handbook is not published under https://download.deegree.org/documentation/.

The documentation shall be published under https://download.deegree.org/documentation/ogcapi/.

Is your feature request related to a problem? Please describe.
deegree OGC API is missing the implementation of OGC API Tiles - Part 1: Core Standard 1.0.0: https://docs.ogc.org/is/20-057/20-057.html

Describe the solution you'd like
deegee OGC API shall provide an implementation.

Describe alternatives you've considered
none

Additional context
none

Describe the bug
Requesting features with a request containing a BBOX returns features which are not located inside the BBOX.

The behavior was detected with the reference implementation: http://cite.deegree.org/deegree-ogcapi-1.3/datasets/kitaeinrichtung/

To Reproduce
Steps to reproduce the behavior:

1. Send request: http://cite.deegree.org/deegree-ogcapi-1.3/datasets/kitaeinrichtung/collections/KitaEinrichtungen/items?f=json&bbox=177.0000000,65.0000000,-177.0000000,70.0000000
2. Compare returned features with BBOX of request:

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "id": "APP_KITAEINRICHTUNGEN_1010263",
      "geometry": {
        "type": "Point",
        "coordinates": [
          10.010474613490274,
          53.60929655136682
        ]
      },
...

Expected behavior
Only features located inside the BBOX shall be returned.

Additional context
This error was detected via the OGC CITE ETS using the code provided by this PR: opengeospatial/ets-ogcapi-features10#220

Current multibranch pipeline setup on Jenkins https://buildserver.deegree.org/view/deegree-ogcapi/job/ogcapi-pr/ doesn't work with https://github.com/deegree/deegree-ogcapi/blame/main/jenkinsfiles/build/Jenkinsfile.

Currently deegree ogcapi requires unmerged PR for deegree 3.5.
These PR needs to be merged to finalize deegree ogcapi version 1.3 and release:

• deegree/deegree3#1180

Describe the bug
The Storage CRS as specified in "OGC API Features Part 2: Coordinate Reference Systems" shall
be one of the CRS identifiers from the list of supported CRS identifiers (Requirement 4).
Right now the CRS name is returned for the the storage CRS. So it is not an identifier and thus also not part of the list of supported CRS identifiers.

To Reproduce
Example case:

1. Configure storage CRS in a feature store as http://www.opengis.net/def/crs/EPSG/0/4258
2. Configure OGC API Features for this feature store
3. When accessing the collections the stated storage CRS is ETRS89

Expected behavior

• the storage CRS should be specified as identifier instead of as CRS name
• it should be possible to align the list of supported CRS identifiers with the storage CRS identifier

Screenshots

• prepare and build release v1.3
• publish schema files for OGC API - #19
• publish documentation for OGC API - #20
• publish release

Currently the element MetadataURL in deegreeOAF is mandatory as defined in https://github.com/deegree/deegree-ogcapi/blob/main/deegree-ogcapi-features/src/main/resources/META-INF/schemas/ogcapi/features/3.4.0/features.xsd#L59. The element shall be optional.

Also the documentation doesn't explain when to define a Dataset inside deegreeOAF (as defined in https://github.com/deegree/deegree-ogcapi/blob/main/deegree-ogcapi-features/src/main/resources/META-INF/schemas/ogcapi/features/3.4.0/features.xsd#L27) or to define the link to the metadata via the deegree webservices services/service_metadata.xml element as defined in https://github.com/deegree/deegree3/blob/327e7876b43c3885747840d5edc83df2940bc36a/deegree-services/deegree-services-commons/src/main/resources/META-INF/schemas/services/metadata/3.4.0/metadata.xsd#L19.

Use the deegreeOAF/Metadata/MetadataURL when you have a metadata set describing all OGC API Feature Collections. Use the deegreeServicesMetadata/DatasetMetadata/Dataset when you have a metadata set for each collection.

Describe the bug
When StorageCRS is configured to EPSG:4326 (see here deegree/deegree-workspaces#17) the calculated coordinates of the collection and items view seem to be different.

This is the spatial extent of collection KitaEinrichtungen retrieved via [API_ENDPOINT]/datasets/kitaeinrichtung/collections/KitaEinrichtungen?f=json:

  "extent": {
    "spatial": {
      "bbox": [
        [
          4.511343502479566,
          0.00048162875265936306,
          4.511348125125168,
          0.0004843912278179983
        ]
      ],
      "crs": "http://www.opengis.net/def/crs/OGC/1.3/CRS84"
    }
  },

This is the geometries of the features retrieved via [API_ENDPOINT]/datasets/kitaeinrichtung/collections/KitaEinrichtungen/items?f=json:

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "id": "APP_KITAEINRICHTUNGEN_1010002",
      "geometry": {
        "type": "Point",
        "coordinates": [
          9.955169041803735,
          53.55926028699146
        ]
      },
...
    {
      "type": "Feature",
      "id": "APP_KITAEINRICHTUNGEN_1010467",
      "geometry": {
        "type": "Point",
        "coordinates": [
          10.105296352572411,
          53.64460438880249
        ]
      },
...
    {
      "type": "Feature",
      "id": "APP_KITAEINRICHTUNGEN_1011056",
      "geometry": {
        "type": "Point",
        "coordinates": [
          9.861767196817834,
          53.59800987268548
        ]
      },
...

The coordinates of the collection view seem to be broken. The items view, however, seems to be correct.

This also leads to the fact that the background map of the map preview of the collection view is not displayed as it is requested with coordinates which do not return any map.
On the other hand, the background map and the data are displayed correctly in the map preview of the item view.

Expected behavior
Coordinates should be correct in both cases.

Desktop (please complete the following information):

• Version: Current main branch
• OS: Ubuntu
• Datasource: postgres/postgis
• Browser: firefox

The configuration shall support the option to customize the text for "Legal Notice" and "Privacy Policy". Currently only the target URL is customizable with LegalNoticeUrl and PrivacyPolicyUrl options in the HtmlView configuration file.

Feature Description:

The full version number is added in the response headers for every API call in the format: API-Version: 1.0.2.

A pull request is made so that this feature can be available as an optional extension to the core deegree OGC API product.

Additional information:

This issue is related to the Dutch API requirement labeled AP-57:

API-57: Return the full version number in a response header

Since the URI only contains the major version, it's useful to provide the full version number in the response headers for every API call. This information could then be used for logging, debugging or auditing purposes. In cases where an intermediate networking component returns an error response (e.g. a reverse proxy enforcing access policies), the version number may be omitted.

The version number must be returned in an HTTP response header named API-Version (case-insensitive) and should not be prefixed.

An example of an API version response header:
API-Version: 1.0.2

Definition of done:

The full version number is added in the response headers for every API call in the format: API-Version: 1.0.2.

A pull request is made so that this feature can be available as an optional extension to the core deegree OGC API product.

This feature should be optional.

Is your feature request related to a problem? Please describe.
I did not find any specific instructions on how the official Docker image is built or how to build the image in general.

Describe the solution you'd like
I think it would be helpful to have instructions on building a Docker image as part of the repository.

Describe alternatives you've considered
I guess there are many alternatives to building Docker images and that may depend on preferences.
You can find an example of a simple Dockerfile for building a Docker image for the project here.
With a respective hook configuration for Docker Hub, in case the Docker Hub automated build based on its GitHub integration would be an option, image labels on the revision, build date and repository URL can be automatically included.

Describe the bug
Nexus repository public-ogcapi misses 3.5.0-SNAPSHOT versions. Generally there don't seem to be any snapshot versions - not sure if there were any others before.
This leads to the build failing if the respective artifact was no previously cached.

To Reproduce
Try building on clean slate with Maven or check the repository content.

Expected behavior
The required build dependencies should be available in the repository.

Screenshots

Example error from Maven build:

Error:  Failed to execute goal on project deegree-ogcapi-datasets: Could not resolve dependencies for project org.deegree:deegree-ogcapi-datasets:jar:1.3-SNAPSHOT: The following artifacts could not be resolved: org.deegree:deegree-core-commons:jar:3.5.0-SNAPSHOT, org.deegree:deegree-core-workspace:jar:3.5.0-SNAPSHOT: Could not find artifact org.deegree:deegree-core-commons:jar:3.5.0-SNAPSHOT in deegree-ogcapi-repo (https://repo.deegree.org/repository/public-ogcapi/) -> [Help 1]

When no HtmlView is configured the link on "Help" reloads the page. Expected is that the help page is opened in a new window.

Describe the bug
Build is failing because repository public-ogcapi referenced here seems to be not available.
Is this a temporary issue (e.g. related to maintenance)? Or is this repository no longer available?

To Reproduce
Steps to reproduce the behavior

1. Run build with Maven, e.g. mvn install -DskipTests=true

Expected behavior
The repository for the build dependencies should be available.

Screenshots

Additional context
I tried using the "public" repository instead, which works in finding the related dependencies, but it seems those are not up-to-date with what the ogcapi project needs, since then the build complains about a missing class org.deegree.services.config.ApiKey which cannot be found in the current deegree3 main branch.
What version/branch of deegree is used as source for the ogcapi dependencies?

Is your feature request related to a problem? Please describe.
deegree OGC API is not implementing OGC API Features - Part 3 - Filtering (DRAFT): http://docs.ogc.org/DRAFTS/19-079r1.html

Describe the solution you'd like
deegree OGC API is providing an implementation of Part 3 - Filtering for HTML encoding.

Describe alternatives you've considered
none

Additional context
none

Currently the user document is missing a statement of the license under which the source code of deegree OGC API is published and also the license of the documentation itself.
The proposed licenses for the documentation are

• GNU Free Documentation License
  or
• CC BY

Same license should be applied to https://github.com/deegree/deegree3/blob/main/deegree-services/deegree-webservices-handbook which is referenced.

Improvement required as proposed in #43 to use the collection ID instead of the title.