# Field analyzer for matching concepts and names
**URL:** https://discuss.elastic.co/t/field-analyzer-for-matching-concepts-and-names/254521
**Category:** Elasticsearch
**Created:** [November 6, 2020, 11:42am UTC](https://discuss.elastic.co/t/field-analyzer-for-matching-concepts-and-names/254521 "2020-11-06T11:42:42Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@jporzelt](https://discuss.elastic.co/u/jporzelt)
#### Post date: [November 6, 2020, 11:42am UTC](https://discuss.elastic.co/t/field-analyzer-for-matching-concepts-and-names/254521/1 "2020-11-06T11:42:42Z")
Dear Elasticsearch community, dear Elastic team,
I have a question about field analyzers that I would like to discuss here.
In our index we have fields (field _cities_ in the below example) that store known concepts or names that are constructed of single or multiple terms. We would like to do queries with the default operator _AND_ so all query terms have to match in at least one of the search fields.
Given the following document
```auto
{
"title": "Nice Cities",
"cities": ["Basel", "New York"]
}
```
I would like to have the following query behavior:
| Query | Doc matches |
| --- | --- |
| nice basel | ✅ |
| nice new york | ✅ |
| nice basel new york | ✅ |
| nice cities | ✅ |
| new york | ✅ |
| cities | ✅ |
| nice york | ❌ |
| york | ❌ |
For the queries I tried the following two types
```auto
GET discuss_elastic/_search
{
"query": {
"multi_match": {
"query": "nice new york",
"fields": ["title", "cities"],
"operator": "AND",
"type": "cross_fields"
}
}
}
GET discuss_elastic/_search
{
"query": {
"simple_query_string": {
"query": "nice new york",
"fields": ["title", "cities"],
"default_operator": "AND",
"flags": "WHITESPACE"
}
}
}
```
I already experimented with the following index design that is producing _shingles_ for the _cities_ field but unfortunately it does not work out.
```auto
PUT discuss_elastic
{
"settings": {
"number_of_shards": "1",
"number_of_replicas": "0",
"analysis": {
"filter": {
"shingle_filter": {
"type": "shingle",
"min_shingle_size": 2,
"max_shingle_size": 4
}
},
"analyzer": {
"cities_query_analyzer": {
"tokenizer": "ws_dot_tokenizer",
"filter": [
"lowercase",
"shingle_filter"
]
},
"cities_index_analyzer": {
"tokenizer": "keyword",
"filter": [
"lowercase"
]
}
},
"tokenizer": {
"ws_dot_tokenizer": {
"type": "char_group",
"tokenize_on_chars": [
"whitespace",
"."
]
}
}
}
},
"mappings": {
"properties": {
"title": {
"type": "text"
},
"cities": {
"type": "text",
"analyzer": "cities_index_analyzer",
"search_analyzer": "cities_query_analyzer"
}
}
}
}
PUT discuss_elastic/_doc/1
{
"title": "Nice Cities",
"cities": ["Basel", "New York"]
}
```
I tried to use the _cities\_query\_analyzer_ for both indexing and query but this then behaves like a normal text fields and therefore also matches the query "nice york".
---
### Author:  [@jporzelt](https://discuss.elastic.co/u/jporzelt)
#### Post date: [November 7, 2020, 9:24am UTC](https://discuss.elastic.co/t/field-analyzer-for-matching-concepts-and-names/254521/2 "2020-11-07T09:24:22Z")
In my initial post, I had the _cities\_query\_analyzer_ for both indexing and querying which was a c+p failure.
Anyone an idea how to archive the desired behavior?
---
### Author:  [@jporzelt](https://discuss.elastic.co/u/jporzelt)
#### Post date: [November 10, 2020, 9:14am UTC](https://discuss.elastic.co/t/field-analyzer-for-matching-concepts-and-names/254521/3 "2020-11-10T09:14:37Z")
The solution I tried was inspired by the book "Relevant Search" by @softwaredoug and @JnBrymn. Maybe you guys can help here 🙂
---
### Author:  [@jporzelt](https://discuss.elastic.co/u/jporzelt)
#### Post date: [November 17, 2020, 2:38pm UTC](https://discuss.elastic.co/t/field-analyzer-for-matching-concepts-and-names/254521/4 "2020-11-17T14:38:12Z")
nobody an idea?
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [December 15, 2020, 2:38pm UTC](https://discuss.elastic.co/t/field-analyzer-for-matching-concepts-and-names/254521/5 "2020-12-15T14:38:18Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.