# Geo\_shape questions

**URL:** <https://discuss.elastic.co/t/geo-shape-questions/10387>\
**Category:** Elasticsearch\
**Created:** [January 17, 2013, 9:58am UTC](https://discuss.elastic.co/t/geo-shape-questions/10387 "2013-01-17T09:58:32Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![gjdev](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/gjdev/32/2528_2.png) [@gjdev](https://discuss.elastic.co/u/gjdev)\
**Post date:** [January 17, 2013, 9:58am UTC](https://discuss.elastic.co/t/geo-shape-questions/10387/1 "2013-01-17T09:58:32Z")

</div>

I posted a message yesterday, but somehow it didn't get on the list. Trying  
again....

I have some questions/remarks about the (incredibly useful) geo\_shape type  
and filters.

- Are there plans to support "Pre-Indexed-Shapes" also in documents, i.e.  
specify a pre-indexed shape to be indexed with a new document, instead of  
adding the geometry itself to that document? I would expect that in many  
use-cases the same geometries will be indexed with multiple docs. Just like  
with filters/queries the performance could benefit quite a lot if the  
indexer could just copy the hashes over from an already indexed geometry.

- Imho allowing a serialisation of a geometry as e.g. WKT would not only  
trim-down on the size of documents, but also on the work that elasticsearch  
needs to do for serializing/deserializing geometries. Polygons quickly  
become really big when expressed in JSON... Is this something that is  
considered and/or that will be accepted when provided in a decent  
pull-request?

- A bit more documentation about how the combination of distance\_error\_pct  
and tree\_levels affects the precision/results of filters would really be  
appreciated. From the docs and code I'm having a hard time understanding  
the consequences of altering both values on filters and indexes. What  
exactly does distance\_error\_pct, and how does it affect e.g. an  
intersection filter?

- Quote from the docs: "Because of current limitations of the algorithm,  
very large indexed shapes are not deemed to intersect with very small  
filter shapes". Are there any plans to fix this? Assuming the algorithmic  
problem is that large shapes are only hashed up to a maximum depth, there  
are a couple of ways to fix this. E.g. the indexer could add an extra field  
with the hashes from only the deepest hash-level it uses for that geometry.  
The intersection filter could use this by extending (boolean or) the  
current filter with a term-filter on that field for all parents of the  
hashes it currently uses for searching. That way larger shapes that  
intersect will be included, and smaller shapes that only happen to share a  
parent won't be included.

- The algorith for "within" (In TermQueryPrefixStrategy) could be improved  
(imho). It's currently inconsistent for geometries that are equal or just a  
tiny bit smaller than the filter-geometry, and I think that could easily be  
fixed. I've filed ann issue about this yesterday, so I won't get further  
into it here, see [https://github.com/elasticsearch/elasticsearch/issues/2552](https://github.com/elasticsearch/elasticsearch/issues/2552)

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:** [July 6, 2017, 2:55am UTC](https://discuss.elastic.co/t/geo-shape-questions/10387/2 "2017-07-06T02:55:57Z")

</div>