Invalid WFS geojson output when requesting propertyName

[KatAgnew]

It's been reported to me by a developer that when they are performing WFS getfeature requests on ArcGIS Servers (both 10.6.1 & 10.9.1) with PropertyName, an invalid geojson is returned (if requested as the output format). A propertyName request will result in a dangling comma in the geometry field (making in invalid). There appears to be an assumption in the geojson template that there will always be a "coordinate" in associated feature to fill in this section before the closing curly bracket.

Example WFS request:
https://services.ga.gov.au/gis/services/Topographic_Map_Indexes/mapserver/wfsserver?request=GetFeatu...

Example Output:
{"type":"FeatureCollection","crs":{"type":"name","properties":{"name":"EPSG:4326"}},"features":[
{"type":"Feature","geometry":{"type":"multipolygon",},"properties":{"GmlID":"General_Reference_Maps_Index_1Million.1","objectid":1,"MAP_NUM":"SG54","st_area_shape_":24.00000000,"st_perimeter_shape_":20.00000000}},
{"type":"Feature","geometry":{"type":"MultiPolygon",},"properties":{"GmlID":"General_Reference_Maps_Index_1Million.2","objectid":2,"MAP_NUM":"SG55","st_area_shape_":24.00000000,"st_perimeter_shape_":20.00000000}},

(note "geometry":{"type":"MultiPolygon",},)

This doesn't appear to be an issue when outputting an xml file as the geometry field appears to be ignored:

eg.
https://services.ga.gov.au/gis/services/Topographic_Map_Indexes/mapserver/wfsserver?request=GetFeatu...

Example Output:

<Topographic_Map_Indexes:General_Reference_Maps_Index_1Million gml:id="General_Reference_Maps_Index_1Million.1">
<Topographic_Map_Indexes:objectid>1</Topographic_Map_Indexes:objectid>
<Topographic_Map_Indexes:MAP_NUM>SG54</Topographic_Map_Indexes:MAP_NUM>
<Topographic_Map_Indexes:st_area_shape_>24.00000000</Topographic_Map_Indexes:st_area_shape_>
<Topographic_Map_Indexes:st_perimeter_shape_>20.00000000</Topographic_Map_Indexes:st_perimeter_shape_>
</Topographic_Map_Indexes:General_Reference_Maps_Index_1Million>

When testing a similar requests on geoserver, the result will return "null" for the "geometry" and continue to generate a valid json output.

Example request on geoserver:
https://services.ga.gov.au/gis/earthresource/wfs?request=GetFeature&version=2.0.0&service=WFS&output...

Example Output:
{"type":"FeatureCollection","features":[{"type":"Feature","id":"ProcessingPlants.42000","geometry":null,"properties":{"ENO":42000,"PLANT_NAME":"Kwinana - Fe"}},{"type":"Feature","id":"ProcessingPlants.42096","geometry":null,"properties":{"ENO":42096,"PLANT_NAME":"Bell Bay"}},{"type":"Feature","id":"ProcessingPlants.42097","geometry":null,"properties":{"ENO":42097,"PLANT_NAME":"Bell Bay - Mn"}},

A work around has been found by not specifying the "&propertyName=" when querying ArcGIS servers, but I believe that the above is still a valid request and the servers should be able to handle a response without a coordinate.

I logged a call with our local ESRI support, but was advised that this was expected behaviour and to not use the "&propertyName=" option.

Just wondering if anyone where has any further ideas?

[soto40]

Briefly: the response from a WFS, provided by ArcGIS Server in GeoJSON format does not follow the RFC 8259 and RFC 7946 standards, if the response is a standalone table (without geometry).

I have the same error as described above when retrieving standalone tables (without geometry) trough a WFS request in GeoJSON format.  The unexpected comma makes the JSON file invalid, so the systems that are willing to get the data from the web service are crashing unless they are ignoring the comma that is inserted against the RFC 8259 standard.

The request that KatAgnew provided as example is not including the "Shape" attribute, therefore the response is a standalone table without geometry, so the problem is not related to the fact that "&propertyName=" was used, but to the fact that a comma is added if the geometry is not present, as in the case of standalone tables.

If the "Shape" attribute is present, then the response looks like this one:

"geometry":{"type":"MultiPolygon","coordinates":[[[[129.02618410,-14.58190918],[129.08459470,-14.58190918],[129.02618410,-14.58190918]]]]}

If the "Shape" attribute is not present, as in the case of standalone tables or when using "&propertyName=" parameter without listing the "Shape" attribute as a property name to be retrieved, the response looks like this one:

"geometry":{"type":"Unknown",}  - for standalone table

"geometry":{"type":"MultiPolygon",}  - for feature classes where Shape is not listed in the propertyName parameter.

This is not an expected behaviour, as the JSON is not valid according to RFC 8259, neither to not use the "&propertyName=" option or to not request standalone tables trough WFS.

The comma can be programmatically removed by ESRI, if quotation marks " are not following after the comma.

However "geometry":null seems to be the correct encoding and not the"geometry":{"type":"Unknown"}, as the geometry type is not unknown. It is known that the geometry is not provided in the case of a standalone table.

Relevant discussions about this topic:

https://github.com/opengeospatial/ogcapi-features/issues/765

https://github.com/opengeospatial/ogcapi-features/issues/16

In the above discussions, Clemens Portele mentioned:

"Yes, features that do not have a geometry are valid. In GeoJSON the geometry member is set to null for these features."

This is inline with the GeoJSON format standard (RFC 7946) https://www.rfc-editor.org/rfc/rfc7946, where in section 3.2 it is written:

A Feature object has a member with the name "geometry". The value of the geometry member SHALL be either a Geometry object as defined above or, in the case that the Feature is unlocated, a JSON null value.