add feature and geometry v03 for minimalist geoJSON compatibility

[petersilva]

It looks like people really object to the simplification of just having a bounding box, and are asking for GeoJSON compatibility. The minimal transformation to achieve geoJSON compatibility as per ET-AT suggestion is to add the requisite fields to the existing payload:

"type": "feature"
"geometry":  < as per geoJSON, polygons, etc... >

Looking at RFC 7946, GEOJSON allows for "Foreign Members" (https://www.rfc-editor.org/rfc/rfc7946.html#page-15) , which can be placed at the top level. So the existing TT-Protocols format, once, "type" and "geometry" are added, is already GeoJSON. There is no need to change anything else for GEOJSON compliance.

@josusky thoughts... would it be easy to update your validator for this?

[petersilva]

by using foreign members we avoid stepping on STAC, and allow implementations to construct links from the fields of the underlying message in a straightforward way. We could also explicitly warn against the "links" element if we would choose to ban it, or simply elide it from the actual message.

[kaiwirt]

My preferred way would be to put the necessary fields into properties and use foreign members only as en exception. Anyway i agree with @golfvert that we first need to agree whether we use GeoJSON or not (+1 for me) and second step will be which properties we need (based on TT-Protocols work), how to name them, and where to put them in the hierarchy

[petersilva]

fwiw the implementation of this in the Canadian stack is "null"... people just create messages the normal way and then set:

import geojson

message["type"] = "Feature"
message["geometry"] = geojson.Point((-115.81, 37.24))   #aka any RFC 7946 compliant geometry...

Existing implementation present in wis2box will accept and forward such messages. and any thing that accept geoJson should as well.

[josusky]

I have updated the schema to validate these two new properties. And created a pull request. However, I am concerned about how the notification producing software will deduce a meaningful geometry. The problem is that it can be time-consuming and sometimes even impossible. The software that is used to exchange data normally does not need to "understand" all the formats. And as far as I can see, the GeoJSON does not allow a "null" geometry so we might need to use some bogus values or something. Why? What is the purpose of all this?

[golfvert]

As explained in the pull request, geometry can be null. The purpose of this geometry field (which can be optional when null) is to permit further filtering before download. Eg if one metadata record covers all SYNOP from France, it will include remote territories. The purpose of the geometry is to allow filtering of messages covering La Réunion. It is a useful bonus, but, not a must...

[antje-s]

A useful and performant filling of the geometry values is also from my point of view a task to be solved. For individual stations possibly via a list that regularly pulls data from Oscar, but for collections and other data/products? Perhaps via metadata, but this would probably also have to be pulled offline beforehand and stored in a mapping file for performance reasons....but as a first pragmatic solution we can set null

[petersilva]

further discussion here: https://github.com/wmo-im/wis2-notification-message