Skip to content
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

Error on get feature info with WMTS added in the TOC #707

Open
catmorales opened this issue Mar 12, 2024 · 4 comments
Open

Error on get feature info with WMTS added in the TOC #707

catmorales opened this issue Mar 12, 2024 · 4 comments
Assignees

Comments

@catmorales
Copy link
Collaborator

catmorales commented Mar 12, 2024

Describe the bug
Since the 2023.02.00-georchestra release, when adding a WMTS in the TOC, the getfeature info request doesn't work and mapstore crashes.

To Reproduce
Steps to reproduce the behavior:

  1. Go to '.https://portail.sig.rennesmetroole.fr.'
  2. Add a layer from "Fonds de Plans"catalogue (layers from geowebcache ), none layer is selected
  3. click on the map everywhere
  4. See error 400 bad request on https://portail.sig.rennesmetropole.fr/geowebcache/service/wmts?service=WMTS&request=GetFeatureInfo&layer=raster:ortho2021&infoformat=text/html&style=&tilecol=1073&tilerow=752&tilematrix=EPSG:3857:11&tilematrixset=EPSG:3857&i=72&j=75

Expected behavior
the feature info popup open with the attributes information of vector layers as usual

Screenshots
ej with cadastre wmts layer but it is the same with orthophoto2021 wmts layer
wmts

Desktop (please complete the following information):

Additional context
We didn't have this problem with the 2022 releases.
We use a standalone geowebcache.
The original data is in EPSG 3948 but published on geoserver in different EPSG 3857, 4326 and 2154.
The mapstore map is in EPSG 3857.

@catmorales
Copy link
Collaborator Author

perhaps linked to #660

@catmorales
Copy link
Collaborator Author

We have the same issue with COG layers

@tdipisa
Copy link
Collaborator

tdipisa commented Mar 12, 2024

@catmorales
The GetFeatureInfo requests on the WMTS layer fails with the following exception:

<?xml version="1.0" encoding="UTF-8"?>
<ExceptionReport version="1.1.0" xmlns="http://www.opengis.net/ows/1.1"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.opengis.net/ows/1.1 http://geowebcache.org/schema/ows/1.1.0/owsExceptionReport.xsd">
  <Exception exceptionCode="TileOutOfRange" locator="TILECOLUMN">
    <ExceptionText>Column 536 is out of range, min: 505 max:510</ExceptionText>
  </Exception>
</ExceptionReport>

I don't know why at the moment, this error doesn't always appear. It seems to depend on the order in which the GFI responses arrive, meaning that if the GFI response for a WMST layer is the first MS does not seems to be able to handle the exception raised by the server. This should be investigated to properly understand the reason since we are not experiencing problems like that on our end therefore it would be the case to take a look also at the tilematrix set definition of involved WMTS layers you have.

We have the same issue with COG layers

In any case I don't see any connection with COG layers, to be honest, and main reasons are:

  • For COG layers the GFI support is still missing
  • The issue is involving WMTS layers

The reason why you have this impression is probably because, together with COG layers in TOC, you have also added one or more WMTS layer.

@dsuren1
Copy link
Collaborator

dsuren1 commented Apr 29, 2024

Investigation outcome

The app crash issue occurs when WMTS responds with TileOutOfRange exception from the response and when the GFI format is HTML, the catch processed output is sent as object instead of text/html string. Due to this HTMLViewer fails to perform string operation and ends with an exception.

However, this doesn't happen with TEXT or PROPERTIES as format

Solution

Modify the GFI wmts exception response based on infoformat. As mentioned above the current error response is an object instead modify the output to return no features were found. Something like this should handle the exception and show other GFI results that has output

return ['text/plain', 'text/html'].includes(params.infoformat) ? {data: 'no features were found'} : { data: { features: []}};

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants