Inconsistent use of `id_field` in provider_def

[webb-ben]

Description
Across pygeoapi providers, there is inconsistent behavior of the id_field parameter as it pertains to the output GeoJSON feature properties. Some providers remove the field from the properties block, while most appear to leave the field in, some explicily pop it from this object.

The primary issue is that pygeoapi lists the id_field column in both the collection queryables and collection schema. However the offered field will only ever be returned as feature id. Some providers even go as far as to make sure the id_field is correctly cast in the offered fields, further confusing me as to the correct behavior.

Another note is that we explicitly exclude the id_field from appear twice in the HTML, suggesting it is expected and tolerable to retain the id_field value both in the properties block and as the feature id.

Steps to Reproduce

1. Visit:
   https://demo.pygeoapi.io/master/collections/dutch_windmills/schema

2. Filter by desired gml_id
   https://demo.pygeoapi.io/master/collections/dutch_windmills/items?gml_id=Molens.1

3. Offered field is not in response with offered key.

Expected behavior
Collection schema are returned in the response with the correct key

Screenshots/Tracebacks
If applicable, add screenshots to help explain your problem.

Environment

• OS: All
• Python version: 3.12
• pygeoapi version: 0.22.dev0

Additional context
Add any other context about the problem here.

[mikemahoney218-usgs]

I had always assumed that poping the field was the intended behavior, in order to not transmit the same data twice.

This does cause some issues when working with the downloaded data in geopandas specifically, as there's a longstanding bug in geopandas meaning the id field isn't read in:
geopandas/geopandas#1208

I'd be very curious if there's anything defining the best practices here -- that geopandas bug makes me suspect that it's at least common to not reproduce the id value inside of properties

[dblodgett-usgs]

When the id has a different attribute name than id -- then I think it's very important to preserve / duplicate the content with the correct attribute name.

To me, it's kind of a simple features access level concern. If it's not in the parameters block, it's not part of the simple features access based abstraction. So the geojson id, which is outside the parameters block, is not really part of the feature attributes. By this logic, the id can share values with one of the parameters as an API convention but the feature attributes should all show up in the geojson properties always.

[mikemahoney218-usgs]

That's fair -- I've sidestepped this by having all my data sources use a column called "id" as their id value, but that's not a real solution (especially when you don't control the incoming data)

[tomkralidis]

Hi all: thanks for the issue. The suppression of the feature provider based id_field is rooted in not duplicating data (every byte counts). Some feature providers (e.g. Elasticsearch) handle this differently because GeoJSON is expected to the underlying input, whereas others need to generate this value explicitly (hence id_field).

Having said this, from a data management perspective, thinking more, I would agree on not suppressing the provenance of a given feature id.