Add support for GeoJSON foreign members

[tukez]

Could this library support GeoJSON foreign members? https://datatracker.ietf.org/doc/html/rfc7946#section-6.1

In short, Feature, FeatureCollection and Geometry should allow custom fields of any type in addition to the fields defined in the spec. This would allow this library to work with GeoJSON extensions.

As implementation, a field: foreignMembers: Map<String, JsonElement>, would be enough.

[P72B]

You can still put your foreignMembers into the properties field.

I see a danger in having foreignMembers allowed in this lib because other geojson libs/parser will may break during schema validation.

[sargunv]

The GeoJson spec allows for foreign members, so I agree we should ensure there's some path to do it. Though ideally, we should validate the approach against a real use case. Are there some examples of common extension formats that make use of foreign members?

Currently, supporting foreign members with a new Map property on GeoJsonObject would require a custom serializer for all geojson objects. Rather than maintaining custom serializers, I think it would be better for GeoJson extensions themselves to be defined as a class with a custom serializer that delegates to the GeoJson serializer for some properties and parses others itself. This would allow the extension itself to also be validated during (de)serialization.

We should probably write a test / example of such an extension serializer to validate it's feasible.

[sargunv]

Here's one foreign member in the wild: MobilityData/GOFS#44

It's a zone_id string on the Feature object within a FeatureCollection.