WFS feature type element geometry type handling fails with adhoc gml namespace prefix

[maelle]

I wonder whether the error at the last line of the code below indicates a problem of the server, or a buglet in ows4r... or some understanding error on my side.

service_url <- "https://prod-geoserver.emodnet-physics.eu/geoserver/ows"
wfs <- ows4R::WFSClient$new(
    service_url,
    serviceVersion = "2.0.0",
    headers = c("User-Agent" = "EMODnetWFS R package 2.0.1.9001 https://github.com/EMODnet/EMODnetWFS"),
    logger = NULL
)
#> Loading ISO 19139 XML schemas...
#> Loading ISO 19115 codelists...

capabilities <- wfs$getCapabilities()
capabilities$getFeatureTypes()[[14]]$getName()
#> [1] "EMODnet:EP_PLATFORMS_MO_ATLAS"
capabilities$getFeatureTypes()[[14]]$getGeometryType()
#> NULL
capabilities$getFeatureTypes()[[14]]$getDescription(pretty = TRUE)
#> Error in data.frame(name = element$getName(), type = element$getType(), : arguments imply differing number of rows: 1, 0

^{Created on 2024-02-28 with reprex v2.1.0}

[eblondel]

Hi @maelle thanks for this. To answer your question in the issue title: No the geometry type cannot be null IF the a geometry element is defined. However it doesn't mean that you are obliged to have geometries. WFS allows to disseminate geometryless data, but in that case you would not have any geometry element declared in the feature type.

In your case it is defined in the feature type (here it's a generic "GeometryType" with no precision on the actual type), but ows4R failed to handle it.

Here is the reason, based the below extract of the Feature type description.

<?xml version="1.0" encoding="UTF-8"?><xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:EMODnet="https://prod-geoserver.emodnet-physics.eu/geoserver/EMODnet" xmlns:Q1="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:wfs="http://www.opengis.net/wfs/2.0" elementFormDefault="qualified" targetNamespace="https://prod-geoserver.emodnet-physics.eu/geoserver/EMODnet">
  <xsd:import namespace="http://www.opengis.net/gml/3.2" schemaLocation="https://prod-geoserver.emodnet-physics.eu/geoserver/schemas/gml/3.2.1/gml.xsd"/>
  <xsd:import namespace="http://www.opengis.net/gml" schemaLocation="http://prod-geoserver.emodnet-physics.eu/geoserver/schemas/gml/2.1.2/feature.xsd"/>
  <xsd:complexType name="EP_PLATFORMS_MO_ATLASType">
    <xsd:complexContent>
      <xsd:extension base="Q1:AbstractFeatureType">
        <xsd:sequence>
          <xsd:element maxOccurs="1" minOccurs="0" name="geometry" nillable="true" type="Q1:GeometryPropertyType"/>

This feature type description combines 2 versions of the GML standard (1st time I see this), where GML 2 is not defined with "gml" as xmlns because it is used for the GML 3.2 namespace. Instead a "Q1" is used for the GML 2. ows4R assumes GML 2 xmlns was handled with "gml" prefix, wrongly.

I've made a patch, tested successfully on your example.

[eblondel]

Hum the patch is breaking the generic behavior, so I need to revert back.

WFS 2.0 supposes the GML 3.2.1 is used as GML namespace. Here i'm not sure why the GML 2 is referenced, in principle this is not compliant with WFS 2.0. It seems you are using the app-schema and defined the GML2 as secondary namespace.

Need to think in a better patch

[maelle]

Thanks!!

[maelle]

Please tell me if some questions need to be forwarded to that server's maintainers, in case what they are doing is really unusual? (I don't know anything about this)

[eblondel]

@maelle You can ask him to confirm that the Geoservet app-schema is used and GML 2 was declared as secondary namespace, but apart from this I don't really see how this could be possible.
Anyway the patch makes the trick

[maelle]

@bart-v do you know more about the question above?

@eblondel thank you!!

[bart-v]

Not really, we are not managing this geoserver, and we never touch things like secondary namespace

[eblondel]

Ah ok, I though you were the manager, no problem.
This seems to be the result of the Geoserver app-schema extension, the reason why it was not managed so far by ows4R. To my knowledge this is the only place where you can define a secondary namespace, in particular here since 2 versions of the GML schema are handled in the same service response.

@maelle I believe we can close this issue.

[maelle]

Thank you!!