Implement Foreign Members

[IIITM-Jay]

Hi @patricoferris Sir, there is a section called Foreign Members in RFC that states that

Members not described in this specification ("foreign members") MAY be used in a GeoJSON document. Note that support for foreign members can vary across implementations, and no normative processing model for foreign members is defined. Accordingly, implementations that rely too heavily on the use of foreign members might experience reduced interoperability with other implementations.

I really wanted to work on this as it would be great if this library also supports this feature of GeoJSON and need your guidance as well on how can we proceed on above implementation.

Shall I work on this...

[patricoferris]

Thanks for opening the issue @IIITM-Jay.

We could add something for this, I'm not sure how useful it would be though. At the moment users will parse some string into a JSON representation of their choice and then use Geojson.of_json json to get a Feature, FeatureCollection or a Geometry (i.e. a Geojson.t).

I guess we could provide a

val foreign_members : t -> json

that would strip out the normal fields and only leave "foreign members"?

[IIITM-Jay]

Hi @patricoferris Sir, Good Morning! There is a mentioning of name/value pair in the RFC which is a bit unclear for writing the function for implementing foreign members. Your above explanation really makes sense and quite understandable too, but may I request for few suggestions on the same on how can I proceed further with writing of the function code using name/value pair (an exemplar pseudocode may be helpful here) _I mean, we have to create some get_foreign_members function that can work for us...._, (if I'm not wrong)

For example, in the (abridged) Feature object shown below

{ "type": "Feature", "id": "f1", "geometry": {...}, "properties": {...}, "title": "Example Feature" }

the name/value pair of "title": "Example Feature" is a foreign member. When the value of a foreign member is an object, all the descendant members of that object are themselves foreign members.

[IIITM-Jay]

Hi sir @patricoferris , I am waiting for your response as soon as possible (if you are not busy with some works, forgive me too) in order to create a PR on this.

[patricoferris]

Hey, sorry for the delay.

A JSON object can be thought of as a name-value pair list (in fact that is what we interpret them as): https://github.com/geocaml/ocaml-geojson/blob/a03a5c36174be974bc6099cf60e645f1d9a6f376/src/geojson/geojson_intf.ml#L52

Foreign members are name-value pairs in the Feature object that do not belong i.e. the RFC does not make reference to them such as "title": "Example Feature". The point it is making is that all name-value pairs should be treated as such even if a value is an object such as "title": { "english": "Example Feature" }. The value here is an object and it could even look like a Feature or Geometry object, but must be treated as a foreign member.

The best we can do is provide either a json value for the name-value pairs or perhaps even a (string * json) list in fact, which might be better.

I don't know if that's any clearer 😅, let me know if not :))

[IIITM-Jay]

Hi Sir @patricoferris , I have opened up a PR but need your suggestions and guidance on the same.

[IIITM-Jay]

Hi @patricoferris , Now the work is being going on in the PR #46. Sorry for the inconvenience caused. :pleading_face:

[patricoferris]

Fixed in #46