WFS query returns unhandy MULTISURFACE geometries

[fdetsch]

I was wondering why some WFS queries in {ows4R} return MULTISURFACE geometries. As documented numerously (e.g. r-spatial/sf#748, How to simplify a MULTISURFACE [...] geometry? - Stack Overflow), these can be tedious to handle in R as even very basic operations like

• sf::st_coordinates(),
• as(..., "Spatial"),
• terra::vect() and
• plot()

are not supported. For demonstration purposes, take the following example:

cli = ows4R::WFSClient$new(
  "https://geodatendienste-landesplanung-hessen.de/geoserver/suedhessen/wfs"
  , serviceVersion = "2.0.0"
)

features = cli$getFeatures(
  "suedhessen:gruenzug"
)

sf::st_geometry_type(features[1L, ])
# [1] MULTISURFACE

plot(features[1L, ])

Error in xy.coords(x, y, xlabel, ylabel, log) :
  'x' is a list, but does not have components 'x' and 'y'

For reference, here is the corresponding {owslib} workflow in Python that produces regular MultiPolygon features:

from geopandas import read_file
from owslib.wfs import WebFeatureService

cli = WebFeatureService(
    'https://geodatendienste-landesplanung-hessen.de/geoserver/suedhessen/wfs',
    version='2.0.0'
)

response = cli.getfeature('suedhessen:gruenzug')
result = read_file(response)

result.iloc[[0]].geom_type
# 0    MultiPolygon
# dtype: object

result.iloc[[0]].plot()

(Note: my intention is not to pit Python and R against each other, and {owslib} just serves for demonstration purposes)

[eblondel]

Answer is simple: WFS 2.0 delivers multisurface and not multipolygons, so that is default behaviour that sticks with the OGC standard. If the python library delivers multiPolygons this is a deviation from the standard they might have developed an additional logic to revert to multipolygons in the response. Le jeu. 19 déc. 2024, 11:24, Florian Detsch ***@***.***> a écrit :

…

I was wondering why some WFS queries in {ows4R} return MULTISURFACE geometries. As documented numerously (e.g. r-spatial/sf#748 <r-spatial/sf#748>, How to simplify a MULTISURFACE [...] geometry? - Stack Overflow <https://stackoverflow.com/questions/68810009/how-to-simplify-a-multisurface-curvepolygon-or-compoundcurve-geometry>), these can be tedious to handle in R as even very basic operations like - sf::st_coordinates(), - as(..., "Spatial"), - terra::vect() and - plot() are not supported. For demonstration purposes, take the following example: cli = ows4R::WFSClient$new( "https://geodatendienste-landesplanung-hessen.de/geoserver/suedhessen/wfs" , serviceVersion = "2.0.0" ) features = cli$getFeatures( "suedhessen:gruenzug" ) sf::st_geometry_type(features[1L, ])# [1] MULTISURFACE plot(features[1L, ]) Error in xy.coords(x, y, xlabel, ylabel, log) : 'x' is a list, but does not have components 'x' and 'y' For reference, here is the corresponding {owslib} workflow in Python that produces regular MultiPolygon features: from geopandas import read_filefrom owslib.wfs import WebFeatureService cli = WebFeatureService( 'https://geodatendienste-landesplanung-hessen.de/geoserver/suedhessen/wfs', version='2.0.0' ) response = cli.getfeature('suedhessen:gruenzug')result = read_file(response) result.iloc[[0]].geom_type# 0 MultiPolygon# dtype: object result.iloc[[0]].plot() image.png (view on web) <https://github.com/user-attachments/assets/c9c64641-309c-4900-8604-42c882991668> (Note: my intention is not to pit Python and R against each other, and {owslib} just serves for demonstration purposes) — Reply to this email directly, view it on GitHub <#132>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKDK3AII25EISCQOYIJYTL2GKNFPAVCNFSM6AAAAABT4U5OJWVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZXG4YTGOJRGI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>