-
Notifications
You must be signed in to change notification settings - Fork 8
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
Features returned from WFS are unexpectedly of geometry type CURVEPOLYGON #40
Comments
Hi @odgersn do you have the possibility to send me a test token by email so I could test your WFS and troubleshoot this? Thanks |
Hi @odgersn thanks for this, i had a look. Unfortunately, the management as CURVEPOLYGON comes from upstream from sf package / gdal driver for GML. The WFS 2.0.0 handles by default GML 3.2 as format, hence this geometry type, which I think is the correct behavior from the standard WFS/GML viewpoint, but then indeed we can't handle it properly with sf. I tried to use a lower version of WFS with your service (1.0.0 or 1.1.1) but with no effect (1.0.0 seems unsupported, and 1.1.1 seems to return a 2.0.0 response). However I found a simple workaround to make sure you can retrieve polygons, and this consists in asking the WFS to return result in GML v2, by adding
Let me know if it works for you |
@odgersn did you have a chance to test the above solution? |
Hi Emmanuel, I'm sorry for not getting back to you sooner. Yes your query works, but not quite as I expected it to work. I ran your query with the following amendment in order to set the crs correctly:
It returns an sf data frame of POLYGON features. Excellent. But when I plot the geometry, the results are odd. This is what I see when I run But this is what I should see: I took a closer look at
I took another look at the BBOX in the WFS query and I noticed that the coordinates were in the form
But this just returns an empty data frame, which I would expect to see if my original WFS BBOX had the coordinates in the correct order after all (because that would mean that the coordinates of the new BBOX were out of order, and don't intersect with the target area):
I don't know how else to diagnose what's going on. I've since deleted the test token; I'd have to reissue you another one if you want to test for yourself. |
@odgersn back from my holidays. yes please send me a test token by email I will test it |
@odgersn in #42 I've added the possibility to manage other WFS output formats, such as json or csv. This feature can improve a lot data retrieval as the default format (GML) is more verbose and time consuming to handle. I've tried to use another format in your case, and it seems to fix the issue. To add an polys <- wfs$getFeatures(
typeName = "layer-48076",
cql_filter = "bbox(GEOMETRY,5138900,1568632,5172362,1610673)", outputFormat = "json"
) BTW, we still have an issue with CRS which is not detected in this request. I will investigate this. Let me know |
Hi,
I am trying to retrieve polygons from a WFS server using the following:
This works, but the geometry type of the returned features in my
polys
object isCURVEPOLYGON
, which I did not expect. This is inconvenient because curvepolygons are not fully supported by sf (therefore I can't cast the features to a supported type).When I test the same query in a web browser, the geometry type of the features in the result is
gml:Polygon
, so I assumed the geometry type of mypolys
object would bePOLYGON
orMULTIPOLYGON
.Are curvepolygons really the correct geometry type in this case, or did I make a mistake somewhere? Am I just misunderstanding something?
Thanks,
Nathan
The text was updated successfully, but these errors were encountered: