# GeoShape: Consuming more heap on data node

**URL:** <https://discuss.elastic.co/t/geoshape-consuming-more-heap-on-data-node/203001>\
**Category:** Elasticsearch\
**Created:** [October 10, 2019, 10:23am UTC](https://discuss.elastic.co/t/geoshape-consuming-more-heap-on-data-node/203001 "2019-10-10T10:23:59Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![pokaleshrey](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/pokaleshrey/32/48680_2.png) [@pokaleshrey](https://discuss.elastic.co/u/pokaleshrey)\
**Post date:** [October 10, 2019, 10:23am UTC](https://discuss.elastic.co/t/geoshape-consuming-more-heap-on-data-node/203001/1 "2019-10-10T10:23:59Z")

</div>

Version 7.1.1

My mapping setting consists of following:

> "geometry": {  
> "type": "geo\_shape",  
> "tree": "quadtree",  
> "precision": "8m"  
> }

When i check _/\_segments?verbose=true_, i can see my maximum _memory\_in\_bytes_ (memory occupied on heap) is occupied by _geometry_ field. All other text fields occupy very less heap.

I understand that geo\_shape comes at cost of more memory and disk space.

**Query:**  
Do we have a way wherein we can store this in a compressed format and still be able to query ?

---

<div class="post-metadata">

**Author:** ![Ignacio\_Vera](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ignacio_vera/32/36674_2.png) [@Ignacio\_Vera](https://discuss.elastic.co/u/Ignacio_Vera)\
**Post date:** [October 10, 2019, 10:38am UTC](https://discuss.elastic.co/t/geoshape-consuming-more-heap-on-data-node/203001/2 "2019-10-10T10:38:35Z")

</div>

Hi,

Have you tried the new [indexing strategy](https://www.elastic.co/guide/en/elasticsearch/reference/7.1/geo-shape.html#geoshape-indexing-approach) introduced in ES 6.6.0? It still have some limitations but the cost of memory and disk space should be much lower.

---

<div class="post-metadata">

**Author:** ![pokaleshrey](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/pokaleshrey/32/48680_2.png) [@pokaleshrey](https://discuss.elastic.co/u/pokaleshrey)\
**Post date:** [October 10, 2019, 1:05pm UTC](https://discuss.elastic.co/t/geoshape-consuming-more-heap-on-data-node/203001/3 "2019-10-10T13:05:28Z")

</div>

Hi @Ignacio_Vera,  
Thanks for your reply.  
I have seen this strategy but have not tried it yet.

The reason being, we had current strategy since 6.4.1 and gave us accurate results.

Can you give an insight about how the 6.6.1 strategy differs from the one we have used, in terms of accuracy ?

---

<div class="post-metadata">

**Author:** ![Ignacio\_Vera](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ignacio_vera/32/36674_2.png) [@Ignacio\_Vera](https://discuss.elastic.co/u/Ignacio_Vera)\
**Post date:** [October 11, 2019, 12:16pm UTC](https://discuss.elastic.co/t/geoshape-consuming-more-heap-on-data-node/203001/4 "2019-10-11T12:16:26Z")

</div>

The recursive strategy is based on describing the shape using the grid provided (in your case a quad tree). That means the logic computes all the cells that intersects with the indexed shapes at the given precision and stores that information in the inverted index.

Every cell is described as a prefix path and that goes into the terms dictionary. The higher the precision the more cells you need to describe your shape and the longer those paths will be. This dictionary is loaded into heap so that is the reason you see high heap usage for that field. Unfortunately the only ways to decrease heap usage would be to index your shapes at a lower precision, either using `precision` or `distance_err_pct` parameters.

The new indexed strategy is based on Lucene's BKD tree. Shapes are vectorised using triangles and stored in the tree as a bounding box plus some extra information that helps reconstructing the original triangle. The precision of the shapes is only limited to the encoding used for storing those vectors (1e-7 decimal degree precision).

The result is much faster indexing throughput, smaller index, smaller heap footprint and in most cases faster query throughput. And there is no need to set any extra parameter in order to get your data loaded into ES :).

---

<div class="post-metadata">

**Author:** ![pokaleshrey](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/pokaleshrey/32/48680_2.png) [@pokaleshrey](https://discuss.elastic.co/u/pokaleshrey)\
**Post date:** [October 14, 2019, 4:09am UTC](https://discuss.elastic.co/t/geoshape-consuming-more-heap-on-data-node/203001/5 "2019-10-14T04:09:48Z")

</div>

You are awesome. Thanks 👌

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [November 11, 2019, 4:10am UTC](https://discuss.elastic.co/t/geoshape-consuming-more-heap-on-data-node/203001/6 "2019-11-11T04:10:01Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.