[Maps] Implement fields and bounds retrieval on GeoJsonFileSource

[thomasneirynck]

Summary

Makes two additions:

• add VectorSource#getFields implementaiton to GeoJsonFileSource. Does this by adding an internal __fields property. This enables dynamic styling for this source.
• add bounds-retrieval to GeoJsonFileSource. This enables auto-fit (see below for lengthy explanation)

---

This blocks #88416. This PR would enable for ML to style the anomalies based on a custom color scheme, as well as get the auto-fitting behavior on startup.

---

Clients would use this like this:

const geojsonLayer: VectorLayerDescriptor = {
      type: 'VECTOR',
      id: 'foobar1',
      style: {
        properties: {
          fillColor: {
            type: STYLE_TYPE.DYNAMIC,
            options: {
              customColorRamp: [
                {
                  stop: 0,
                  color: '#FF0000',
                },
                {
                  stop: 1,
                  color: '#00FF00',
                },
              ],
              field: {
                name: 'foobarnumber',
                origin: FIELD_ORIGIN.SOURCE,
              },
              useCustomColorRamp: true,
            },
          },
        },
      },
      sourceDescriptor: {
        type: SOURCE_TYPES.GEOJSON_FILE,
        __fields: [
          {
            name: 'foobarnumber',
            type: 'number',
          },
          {
            name: 'foobarstring',
            type: 'string',
          },
        ],
        __featureCollection: {
          type: 'FeatureCollection',
          features: [
            {
              type: 'Feature',
              geometry: {
                type: 'Point',
                coordinates: [0, 0],
              },
              properties: {
                foobarnumber: 1,
                foobarstring: 'foobar',
              },
            },
          ],
        },
      },
    }

---

additional context

auto-fit-for-bounds does not work for non-ES sources. This is because auto-fitting implicitly relies on bounds-retrieval to be supported without data syncing

kibana/x-pack/plugins/maps/public/actions/map_actions.ts

Line 118 in 4b2c9de

dispatch(addLayerWithoutDataSync(layerDescriptor));

.

This means that the fallback in vector_layer for sources which are not isBoundsAware does not work if syncData has not completed yet.

kibana/x-pack/plugins/maps/public/classes/layers/vector_layer/vector_layer.tsx

Line 243 in 0ac6e62

return getFeatureCollectionBounds(this._getSourceFeatureCollection(), this.hasJoins());

This approach works for 99% of use-cases, since any vector source is mostly backed by Elasticsearch. It is also important that auto-fit must work without fetching the data.

The GEOJSON_FILE source seems to be the exception.

• It is only used transiently in Maps during the preview-phase of geojson-upload
• It is also used by embeddables (e.g. Uptime, ML) to add layers with custom non-ES data

In order for auto-fitting to work before the data is loaded, the GEOJSON_FILE source needs to support bounds-retrieval.

Rather than changing the implementation of auto-fit, or expanding on the API, the easiest solution would be for GEOJSON_FILE to implement the getBounds method.

For maintainers

• This was checked for breaking API changes and was labeled appropriately

[elasticmachine]

Pinging @elastic/kibana-gis (Team:Geo)

[nreese]

LGTM - just one small comment about a more descriptive test name
code review

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 6778edf

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
maps	684	685	+1

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
maps	2.9MB	2.9MB	+3.6KB

History

• 💚 Build #100967 succeeded 9f06d5b
• 💚 Build #100955 succeeded 9ef7792
• 💚 Build #100206 succeeded 90e0db7
• 💔 Build #98972 failed 9ff82de
• 💔 Build #98743 failed a64ad0d

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream