Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Point-Cloud Filtering

Point-cloud streams let a provider publish many locations in one notification. A subscriber supplies a polygon and receives the notification when any cloud point lies inside the polygon or on its boundary.

Coordinates always use latitude first, then longitude. The canonical JSON forms are:

  • point: [lat,lon]
  • polygon: [[lat,lon],...,[lat,lon]], with the first pair repeated last
  • point cloud: [[lat,lon],...], with at least one point

Point and polygon strings remain accepted by the HTTP API for compatibility. Point clouds accept JSON arrays only. Emitted CloudEvents always use arrays for all spatial identifier values.

Schema

notification_schema:
  observations:
    topic:
      base: observations
      key_order: [date]
    identifier:
      date:
        type: DateHandler
        canonical_format: "%Y%m%d"
        required: true
      point_cloud:
        type: PointCloudHandler
        required: true
        max_points: 10000
        description: >-
          Publishers provide point_cloud as [[latitude, longitude], ...].
          Watch and replay requests provide a closed polygon instead. The
          polygon satisfies this required field; subscribers must not send
          point_cloud.
    payload:
      required: true

The handler must use the reserved point_cloud key. A schema can contain only one PointCloudHandler. The configured max_points defaults to 10,000 and cannot exceed 10,000.

Do not put point_cloud in topic.key_order. Startup rejects that configuration. Cloud coordinates stay in the spatial_point_cloud backend metadata header. The subject contains only normal routing fields. Aviso also stores a spatial_bbox header for coarse rejection before exact matching.

Notify

The provider sends the cloud on /notification:

curl -sS -X POST "http://127.0.0.1:8000/api/v1/notification" \
  -H "Content-Type: application/json" \
  -d '{
    "event_type":"observations",
    "identifier":{
      "date":"20260826",
      "point_cloud":[
        [52.52,13.40],
        [48.14,11.58],
        [52.52,13.40]
      ]
    },
    "payload":{"source":"stations"}
  }'

Duplicate points are valid. Aviso preserves their order. Every latitude and longitude must be finite. Latitude must be in [-90, 90]; longitude must be in [-180, 180].

The canonical point-cloud JSON is limited to 60 KiB. This conservative Aviso interoperability limit is informed by NATS-backed header transport and near-limit round-trip tests. It leaves room for Aviso’s other metadata, but is not a protocol-wide NATS header limit. The point-count limit is checked first.

Watch Or Replay

Subscribers use the reserved polygon query field. They do not send point_cloud:

curl -N -X POST "http://127.0.0.1:8000/api/v1/replay" \
  -H "Content-Type: application/json" \
  -d '{
    "event_type":"observations",
    "identifier":{
      "date":"20260826",
      "polygon":[
        [52.40,13.20],
        [52.40,13.70],
        [52.70,13.70],
        [52.70,13.20],
        [52.40,13.20]
      ]
    },
    "from_id":"0"
  }'

The polygon satisfies a required point_cloud field for watch and replay. Aviso first rejects non-overlapping bounding boxes. It then tests points in their stored order and stops at the first match. Points on an edge or vertex match. A cloud whose points are all outside does not match.

Requests are rejected when they send point_cloud to watch or replay, declare polygon in a point-cloud schema, or combine incompatible spatial filters.

CloudEvent Output

The event reconstructs the provider identifier as JSON:

{
  "data": {
    "identifier": {
      "date": "20260826",
      "point_cloud": [
        [52.52, 13.4],
        [48.14, 11.58],
        [52.52, 13.4]
      ]
    }
  }
}

The request polygon is a filter. It is not substituted into the emitted identifier.