[Backport 2023.01.xx] #9030 improve metadata display interoperability with mapserver/mapproxy (#7865) #9059
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.
Description
Rather small PR but fixing many different bugs in the original implementation in #5190 (which was probably only tested against geoserver), cf georchestra/mapstore2-georchestra#300
Please check if the PR fulfills these requirements
What kind of change does this PR introduce? (check one with "x", remove the others)
Issue
What is the current behavior?
georchestra/mapstore2-georchestra#300
What is the new behavior?
with this (and #7851), i'm able to display metadatas (provided CORS is properly configured in mapstore and geonetwork, still working on that on my production setup) from various geonetworks via
metadataUrl
entries fromGetCapabilities
documents returnedhttps://wms.craig.fr/ortho
(mapserver),https://tiles.craig.fr/ortho/service
(mapproxy, multiple layers) andhttps://tiles.craig.fr/pci/service
(mapproxy, one layer) - all those 3 were previously failing with various different problems described in the issue.Breaking change
Does this PR introduce a breaking change? (check one with "x", remove the other)
loading metadata pointed at by geoserver getcapabilities should still work.
Other useful information
locally i have this diff to
web/client/epics/catalog.js
for printing exceptions, dunno if acceptable:to be probably discussed (feedback from developers more than welcome):
removeWorkspace
from an epic is a good idea, maybe the function should be moved elsewhere ?web/client/utils/ogc/
is the right directory for the mapserver schemaiso19115:2003
type being hardcoded to also acceptTC211
, because even if the WMS 1.3.0 spec says:it also says
An information community may define meanings for other “type” attribute values.
, and mapserver hardcodes/defaults to TC211 in its generatedGetMetadata
links, cf https:/MapServer/MapServer/blob/main/mapmetadata.c#L928 and https://mapserver.org/development/rfc/ms-rfc-82.html - that's also one of the values pushed by geonetwork to geoserver, cf https:/georchestra/geonetwork/blob/georchestra-gn4-4.x/services/src/main/java/org/fao/geonet/api/mapservers/GeoServerRest.java#L573 (im trying to get that fixed cf georchestra/geonetwork#197)