[gdal-dev] ElasticSearch and native geometry

Jonathan Moules jonathan-lists at lightpear.com
Thu Nov 24 14:20:15 PST 2016


Hi Jukka,
I'm still very new to ElasticSearch (so take with plenty of salt!), but 
if you want to keep the geom in _source and calculate on the fly, I 
guess you could maybe try it with one of the scripting languages: 
https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-scripting.html 
- Python's on there so then you'd have access to all of the py-geo stuff.

Of course, assuming it worked, the trade-off would be reduced storage 
for (considerably?) increase processing usage and complexity.

The other option would be to store the native geometry as a "binary" 
datatype - 
https://www.elastic.co/guide/en/elasticsearch/reference/current/binary.html

Cheers,
Jonathan


On 23/11/2016 15:41, Rahkonen Jukka (MML) wrote:
>
> Hi,
>
> What if somebody would like to use ElasticSearch for queries but still 
> somehow get the native geometries included in the output?  The 
> geometry must be re-projected into EPSG:4326 for creating either 
> geo_point or geo_shape, but can anybody suggest a clever way for 
> saving the native geometry? It is of course possible to save it into a 
> text field for example as WKT of JSON but could it be possible to keep 
> the original geometry in “_source” and just create the geo_point or 
> geo_shape on-the-fly or the index?
>
> -Jukka Rahkonen-
>
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20161124/ff44e47b/attachment.html>


More information about the gdal-dev mailing list