Data enrichment using geo_point

[fdartayre]

Elasticsearch Version

9.3.0-SNAPSHOT

Problem Description

Even though the match_field in the geo_match policy can point to an index where it is a geo_point, the actual contents in the documents must conform to the geo_shape format (ie. use WKT or GeoJSON).

We can go in three directions here:

• Document this better
• Disallow geo_point mapped fields in geo_match
• Expand support to geo_point fields in geo_match regardless of format (ie. use correct parser based on original mapping)

Steps to Reproduce

PUT /my-enrich-index
{
 "mappings": {
    "properties": {
      "location": {
        "type": "geo_point"
      }
    }
  }
}

POST /my-enrich-index/_doc?refresh=wait_for
{
  "location": {    
    "lon": 4.0053486386,
    "lat": 50.4697386503
  }
}

PUT /_enrich/policy/my-enrich-policy
{
  "geo_match": {
    "indices": [
      "my-enrich-index"
    ],
    "match_field": "location",
    "enrich_fields": []
  }
}

POST /_enrich/policy/my-enrich-policy/_execute

[2025-11-25T11:58:24,104][INFO ][o.e.i.m.DocumentMapper   ] [yamlRestTest-0][.enrich-locations-policy-1764086303757] Error while parsing document for index [.enrich-locations-policy-1764086303757]: [-1:57] failed to parse field [location] of type [geo_shape] org.elasticsearch.index.mapper.DocumentParsingException: [-1:57] failed to parse field [location] of type [geo_shape]
  at org.elasticsearch.server@9.3.0-SNAPSHOT/org.elasticsearch.index.mapper.AbstractGeometryFieldMapper.onMalformedValue(AbstractGeometryFieldMapper.java:335)
  at org.elasticsearch.server@9.3.0-SNAPSHOT/org.elasticsearch.index.mapper.AbstractGeometryFieldMapper.lambda$parse$1(AbstractGeometryFieldMapper.java:325)
  at org.elasticsearch.server@9.3.0-SNAPSHOT/org.elasticsearch.index.mapper.AbstractGeometryFieldMapper$DefaultMalformedValueHandler.notify(AbstractGeometryFieldMapper.java:124)
  at org.elasticsearch.server@9.3.0-SNAPSHOT/org.elasticsearch.index.mapper.GeoShapeParser.parse(GeoShapeParser.java:47)
  at org.elasticsearch.server@9.3.0-SNAPSHOT/org.elasticsearch.index.mapper.AbstractGeometryFieldMapper.parse(AbstractGeometryFieldMapper.java:325)
  at org.elasticsearch.server@9.3.0-SNAPSHOT/org.elasticsearch.index.mapper.DocumentParser.parseObjectOrField(DocumentParser.java:477)
  at org.elasticsearch.server@9.3.0-SNAPSHOT/org.elasticsearch.index.mapper.DocumentParser.doParseObject(DocumentParser.java:545)
  at org.elasticsearch.server@9.3.0-SNAPSHOT/org.elasticsearch.index.mapper.DocumentParser.parseObject(DocumentParser.java:533)
  at org.elasticsearch.server@9.3.0-SNAPSHOT/org.elasticsearch.index.mapper.DocumentParser.innerParseObject(DocumentParser.java:387)
  at org.elasticsearch.server@9.3.0-SNAPSHOT/org.elasticsearch.index.mapper.DocumentParser.parseObjectOrNested(DocumentParser.java:348)
  at org.elasticsearch.server@9.3.0-SNAPSHOT/org.elasticsearch.index.mapper.DocumentParser.internalParseDocument(DocumentParser.java:157)
  at org.elasticsearch.server@9.3.0-SNAPSHOT/org.elasticsearch.index.mapper.DocumentParser.parseDocument(DocumentParser.java:103)
  at org.elasticsearch.server@9.3.0-SNAPSHOT/org.elasticsearch.index.mapper.DocumentMapper.parse(DocumentMapper.java:128)

[elasticsearchmachine]

Pinging @elastic/es-analytical-engine (Team:Analytics)

[craigtaverner]

I've added a PR to expand test coverage to help clarify the situation. See #138721

The key point is that the mapping of the source index is irrelevant. Can even be keyword, as long as the actual fields are parsable as geo_shape, because the internal enrich index created by the execution of the enrich policy will always create a mapping of geo_shape, regardless of the source index mapping. This also means that if we were to 'fix' this by allowing a source index of geo_point to support an enrich index of geo_point (and therefor enable other geo_point formats as requested here) we'd have a backwards compatibility issue. There are possible ways around that, but none are simple.