Problems using Filter with Latest/Related Features in Stream Service

11-27-2019 07:11 AM
New Contributor II

We are currently setting up a Stream Service and need to use the Latest/Related (L/R) Features for our Webmap.


The Stream Service works fine without L/R Features. The WebSocket (WS) connection is created, filter messages of type

{“filter”:{“where”:”mmsi = ‘123456’”}}

are sent and confirmed (“error”: null) through the WS protocol. Data then proceeds to come through the same connection. Filter can be removed and edited, without issues.

With the L/R enabled, the filtering does not work as expected:

By filtering for “mmsi” (Track_id), the filter is sent via WS, then a new WS connection is opened with “where=mmsi%20%3D%20%123456%27” added to the WS-URL. By removing/editing the filter again a new WS connection is opened. Data is at least coming through.

By filtering for “class” (not a field of Related Features) the filter is sent via WS, no new connection is opened. No data is coming through.

I understand that the WS connection cannot be used for filtering for related features, but we did not even do that yet.

Is this a known issue? What would be the work around?


Kind regards, Markus

0 Kudos
1 Reply
Esri Regular Contributor

Hello Markus -

I was able to reproduce the issue you describe above. I'm not entirely sure that this is something that can be fixed server-side in GeoEvent Server. It looks to me like the client's filter specification is being applied to the stream service subscription without error ... but I'm seeing the web map client-side dropping the stream layer from the web map's content whenever I apply a filter to a stream layer whose stream service specifies Related Features. I don't think that the stream service's Store Latest plays into this issue.

We are investigating the issue and will be in touch through the partner / distributor to work with you on this issue.

Best Regards -


0 Kudos