Failed lookup generates `Cannot read property 'geometry' of null` error

Consider performing a lookup that attaches a topjson as a secondary data source to a standard data table as primary. The specification below shows an example of doing this:

{
  "$schema": "https://vega.github.io/schema/vega-lite/v4.json",
  "data": {
    "values": [{"fips": 499999, "state":"UT"},
               {"fips": 4, "state":"AZ"},
               {"fips": 8, "state":"CO"},
               {"fips": 35, "state":"NM"}]
  },
  "transform": [
    {
      "lookup": "fips",
      "from": {
        "data": {
          "url": "https://vega.github.io/vega-lite/data/us-10m.json",
          "format": { "type": "topojson","feature": "states"}
        },
        "key": "id"
      },
      "as": "geo"
    }
  ],
  "mark": "geoshape",
  "encoding": {
    "shape": {"field": "geo","type": "geojson"},
    "color": {"field": "state","type": "nominal"}
  }
}

However, if any of the lookups fail (in the example above Utah’s FIPS code is incorrect as 499999), the entire specification fails with the error Cannot read property 'geometry' of null.

While this can be remedied by filtering out invalid geoshapes ( {"filter" : "isValid(datum.geo)"}), this shouldn’t be necessary. In contrast, when the topojson is primary and the table secondary, failed lookups simply don’t get encoded, without any need to perform explicit filtering. It would be good to make this default behaviour for topojson as secondary too.

[domoritz]

I have an idea. I what if we always generate a filter for geoshapes? We could make that part of the filterinvalid we already have. Essentially, we add the filter because of the geo mark, and not because of the lookup.

[jwoLondon]

That sounds like an ideal solution. I don’t think there would ever be a situation where a geoshape containing nulls would be needed, so this should have no problematic downstream effects.