Missing GeoJson geometries

[outsideMyBox]

Hi,

in notificationMessageGeoJSON.yaml only two geometry types are included: point and polygon.

But GeoJson supports the following geometry types: Point, LineString, Polygon, MultiPoint, MultiLineString, and MultiPolygon. Defined also there.

Is it intentional to restrict to these 2 types or should the other ones be included as well?

Thanks!

[amilan17]

@outsideMyBox the WNM only allows Point and Polygon and does not allow for other types of GeoJSON geometries.

[tomkralidis]

@outsideMyBox the thinking about constraining geometry to Point or Polygon was to keep the profile simple based on the most common geometries for use cases in the context of the notification message itself (which is designed to provide a high level overview/simple filtering). The discovery metadata (and data, of course) can have any geometric complexity as needed.

[gaubert]

@tomkralidis this question is coming from my team because we commonly have products with two swaths (so two polygons). See for instance this leo product.

It is a very common scenario to have users only interested in a region of the word while our LEO satellites are scanning the entire globe. Users would then like to use the notification messages to filter not only in time by in also in space.
For that reason, we would like to integrate in our api client EUMDAC some filtering based on the geospatial info in the WNM. Indeed using EUMDAC, a user will subscribe to some collection arrivals using the MQTT notifcation mechanism and a filtering can be applied based on the geometry. Having a very simple polygon will force users to open and read all the data items to simply understand the geography.
This is an implementation that we going to do to serve our users community and we believe that other satellite operators will do the same. If more complex geometries are not allowed it would mean generating two different notifcation messages with a degraded version for the WIS2 (with geometry = null for instance).

My proposal would be to allow complex geometries in the WNM standard (they validate) but recommend in the guide to use simple ones as it will be the most common case.

What do you think ?

[tomkralidis]

TT-WISMD 2024-11-27

• dense linestrings can cause issues with WNM size limitations (currently 8Kb)
• one option is to provide a minimum bounding rectangle of a LineString (without breaking the current specification)

It would be valuable to assess this requirement in the next 12-18 months of WIS2 operations (i.e. how WIS2 data consumers are working with WNM as clients)