# Dealing with units **URL:** \ **Category:** Elasticsearch\ **Created:** [March 6, 2012, 7:31am UTC](https://discuss.elastic.co/t/dealing-with-units/6904 "2012-03-06T07:31:42Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Eric\_Jain](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/eric_jain/32/834_2.png) [@Eric\_Jain](https://discuss.elastic.co/u/Eric_Jain)\ **Post date:** [March 6, 2012, 7:31am UTC](https://discuss.elastic.co/t/dealing-with-units/6904/1 "2012-03-06T07:31:42Z")
I'm curious how others here index fields with different units, e.g. 5 miles and 10 km, and support queries (and facets) that then use either miles or km. Given a document with a property like: distance : { value : 5, unit : 'miles' } I want to index: distance : 8046.72, // normalized to m But I'd still like \_source to contain the original value and unit, so the original document can be returned. One way to handle this right now is to index: distance : { // don't index this value : 5, unit : 'miles' }, \_distance : 8046.72 // index this ...and rewrite queries to use \_distance (after converting the values in the query as required). For facets, value\_script can be used. But perhaps there is a better way (e.g. create a custom field type)? ---
**Author:** ![Karussell1](https://avatars.discourse-cdn.com/v4/letter/k/50afbb/32.png) [@Karussell1](https://discuss.elastic.co/u/Karussell1)\ **Post date:** [March 6, 2012, 8:13am UTC](https://discuss.elastic.co/t/dealing-with-units/6904/2 "2012-03-06T08:13:43Z")
You could use multi field type and use one of them for normalization (e.g. to meter) or index both units: distance.km and distance.miles > **[Elasticsearch Platform — Find real-time answers at scale](https://www.elastic.co)** > > Power insights and outcomes with the Elasticsearch Platform and AI. See into your data and find answers that matter with enterprise solutions designed to help you build, observe, and protect. Try Elasticsearch free today. Peter. On Tuesday, March 6, 2012 8:31:42 AM UTC+1, Eric Jain wrote: > I'm curious how others here index fields with different units, e.g. 5 > miles and 10 km, and support queries (and facets) that then use either > miles or km. > > Given a document with a property like: > > distance : { > value : 5, > unit : 'miles' > } > > I want to index: > > distance : 8046.72, // normalized to m > > But I'd still like \_source to contain the original value and unit, so > the original document can be returned. > > One way to handle this right now is to index: > > distance : { // don't index this > value : 5, > unit : 'miles' > }, > \_distance : 8046.72 // index this > > ...and rewrite queries to use \_distance (after converting the values > in the query as required). For facets, value\_script can be used. > > But perhaps there is a better way (e.g. create a custom field type)? ---
**Author:** ![Eric\_Jain](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/eric_jain/32/834_2.png) [@Eric\_Jain](https://discuss.elastic.co/u/Eric_Jain)\ **Post date:** [March 6, 2012, 9:13am UTC](https://discuss.elastic.co/t/dealing-with-units/6904/3 "2012-03-06T09:13:26Z")
On Tue, Mar 6, 2012 at 00:13, Karussell [tableyourtime@googlemail.com](mailto:tableyourtime@googlemail.com) wrote: > You could use multi field type and use one of them for normalization (e.g. > to meter) or index both units: distance.km and distance.miles > > [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/reference/mapping/multi-field-type.html) That looks like a promising approach, though \_source still wouldn't contain the original document, but something like: distance : { distance : { // not indexed value : 5, unit : 'miles' }, si : 8046.72 // indexed } Right? I'd rather not create fields for every supported unit--in some cases there can be quite a few... ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [March 6, 2012, 7:38pm UTC](https://discuss.elastic.co/t/dealing-with-units/6904/4 "2012-03-06T19:38:23Z")
Its better to create index a normalized value with the same unit across all docs. You can still index 5 and miles, but add another field that has a normalized value (for example, in miles), and use that when searching. On Tuesday, March 6, 2012 at 11:13 AM, Eric Jain wrote: > On Tue, Mar 6, 2012 at 00:13, Karussell \<[tableyourtime@googlemail.com](mailto:tableyourtime@googlemail.com) ([mailto:tableyourtime@googlemail.com](mailto:tableyourtime@googlemail.com))\> wrote: > > > You could use multi field type and use one of them for normalization (e.g. > > to meter) or index both units: distance.km and distance.miles > > > > [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/reference/mapping/multi-field-type.html) > > That looks like a promising approach, though \_source still wouldn't > contain the original document, but something like: > > distance : { > distance : { // not indexed > value : 5, > unit : 'miles' > }, > si : 8046.72 // indexed > } > > Right? I'd rather not create fields for every supported unit--in some > cases there can be quite a few... ---
**Author:** ![Eric\_Jain](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/eric_jain/32/834_2.png) [@Eric\_Jain](https://discuss.elastic.co/u/Eric_Jain)\ **Post date:** [March 6, 2012, 8:18pm UTC](https://discuss.elastic.co/t/dealing-with-units/6904/5 "2012-03-06T20:18:48Z")
On Tue, Mar 6, 2012 at 11:38, Shay Banon [kimchy@gmail.com](mailto:kimchy@gmail.com) wrote: > Its better to create index a normalized value with the same unit across all > docs. You can still index 5 and miles, but add another field that has a > normalized value (for example, in miles), and use that when searching. Creating separate, normalized fields is what I'm doing now. But I was wondering how difficult it would be to create a custom "dimension" type that normalizes units, so documents and queries don't need to be pre/post processed explicitly? ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [March 7, 2012, 11:10am UTC](https://discuss.elastic.co/t/dealing-with-units/6904/6 "2012-03-07T11:10:57Z")
You can create a customized type, which expects to accept a json object with the value and unit, and automatically index a normalized field. Hard to answer how difficult it is 🙂 On Tuesday, March 6, 2012 at 10:18 PM, Eric Jain wrote: > On Tue, Mar 6, 2012 at 11:38, Shay Banon \<[kimchy@gmail.com](mailto:kimchy@gmail.com) ([mailto:kimchy@gmail.com](mailto:kimchy@gmail.com))\> wrote: > > > Its better to create index a normalized value with the same unit across all > > docs. You can still index 5 and miles, but add another field that has a > > normalized value (for example, in miles), and use that when searching. > > Creating separate, normalized fields is what I'm doing now. But I was > wondering how difficult it would be to create a custom "dimension" > type that normalizes units, so documents and queries don't need to be > pre/post processed explicitly? ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 3:36am UTC](https://discuss.elastic.co/t/dealing-with-units/6904/7 "2017-07-06T03:36:57Z")