There's very little information about the geopoint "lat_lon" indexation
option.
Can someone describe how queries are leveraging so that I can get a better
understanding of whether that would be helpful in my case?
there's also little information on how to pass an option to the geopoint
mapping is this:
First, you don't need to store the field. Second, by default, when the
lat_lon are not indexed, the values are loaded to memory and used for geo
calculations in memory (like checking bounding boxes, distances and the
like). For things that can use lat_lon that are indexed (like bounding
boxes), then you can configure the relevant geo filter to the the "checks"
instead of in memory, using the indexed lat_lon. Most times, the in memory
option is the one you want.
There's very little information about the geopoint "lat_lon" indexation
option.
Can someone describe how queries are leveraging so that I can get a better
understanding of whether that would be helpful in my case?
there's also little information on how to pass an option to the geopoint
mapping is this:
There's very little information about the geopoint "lat_lon" indexation
option.
Can someone describe how queries are leveraging so that I can get a better
understanding of whether that would be helpful in my case?
there's also little information on how to pass an option to the geopoint
mapping is this:
I understand I should stick with in-memory. I still have a couples
questions for the sake of it:
When is the field loaded in memory? on-demand I presume. Is it loaded
entirely (meaning first request might be slow and all subsequent geo
constrained requests are fast)
How does one configure a mapping in the PUT mapping API. I mean the
syntax is not clear from the website.
Best,
-stan
On Thursday, May 17, 2012 10:32:22 PM UTC+2, kimchy wrote:
First, you don't need to store the field. Second, by default, when the
lat_lon are not indexed, the values are loaded to memory and used for geo
calculations in memory (like checking bounding boxes, distances and the
like). For things that can use lat_lon that are indexed (like bounding
boxes), then you can configure the relevant geo filter to the the "checks"
instead of in memory, using the indexed lat_lon. Most times, the in memory
option is the one you want.
There's very little information about the geopoint "lat_lon" indexation
option.
Can someone describe how queries are leveraging so that I can get a
better understanding of whether that would be helpful in my case?
there's also little information on how to pass an option to the
geopoint mapping is this:
I understand I should stick with in-memory. I still have a couples
questions for the sake of it:
When is the field loaded in memory? on-demand I presume. Is it loaded
entirely (meaning first request might be slow and all subsequent geo
constrained requests are fast)
It is loaded entirely on the first request. In upcoming 0.20 you will be
able to register warmup searches that will make loading (specifically for
new data coming in) faster and less disruptive on the search experience.
How does one configure a mapping in the PUT mapping API. I mean the
syntax is not clear from the website.
Not really sure what the question is here..., what do you not understand?
Maybe gist a sample of what you try and not working so we can fix it.
Best,
-stan
On Thursday, May 17, 2012 10:32:22 PM UTC+2, kimchy wrote:
First, you don't need to store the field. Second, by default, when the
lat_lon are not indexed, the values are loaded to memory and used for geo
calculations in memory (like checking bounding boxes, distances and the
like). For things that can use lat_lon that are indexed (like bounding
boxes), then you can configure the relevant geo filter to the the "checks"
instead of in memory, using the indexed lat_lon. Most times, the in memory
option is the one you want.
There's very little information about the geopoint "lat_lon" indexation
option.
Can someone describe how queries are leveraging so that I can get a
better understanding of whether that would be helpful in my case?
there's also little information on how to pass an option to the
geopoint mapping is this:
If I were to use the lat_lon indexing option (which I'm not as per our
previous discussion). How would I configure the field to do so. Would it be
that way?
I understand I should stick with in-memory. I still have a couples
questions for the sake of it:
When is the field loaded in memory? on-demand I presume. Is it loaded
entirely (meaning first request might be slow and all subsequent geo
constrained requests are fast)
It is loaded entirely on the first request. In upcoming 0.20 you will be
able to register warmup searches that will make loading (specifically for
new data coming in) faster and less disruptive on the search experience.
How does one configure a mapping in the PUT mapping API. I mean the
syntax is not clear from the website.
Not really sure what the question is here..., what do you not understand?
Maybe gist a sample of what you try and not working so we can fix it.
Best,
-stan
On Thursday, May 17, 2012 10:32:22 PM UTC+2, kimchy wrote:
First, you don't need to store the field. Second, by default, when the
lat_lon are not indexed, the values are loaded to memory and used for geo
calculations in memory (like checking bounding boxes, distances and the
like). For things that can use lat_lon that are indexed (like bounding
boxes), then you can configure the relevant geo filter to the the "checks"
instead of in memory, using the indexed lat_lon. Most times, the in memory
option is the one you want.
There's very little information about the geopoint "lat_lon" indexation
option.
Can someone describe how queries are leveraging so that I can get a
better understanding of whether that would be helpful in my case?
there's also little information on how to pass an option to the
geopoint mapping is this:
If I were to use the lat_lon indexing option (which I'm not as per our
previous discussion). How would I configure the field to do so. Would it be
that way?
I understand I should stick with in-memory. I still have a couples
questions for the sake of it:
When is the field loaded in memory? on-demand I presume. Is it loaded
entirely (meaning first request might be slow and all subsequent geo
constrained requests are fast)
It is loaded entirely on the first request. In upcoming 0.20 you will be
able to register warmup searches that will make loading (specifically for
new data coming in) faster and less disruptive on the search experience.
How does one configure a mapping in the PUT mapping API. I mean the
syntax is not clear from the website.
Not really sure what the question is here..., what do you not understand?
Maybe gist a sample of what you try and not working so we can fix it.
Best,
-stan
On Thursday, May 17, 2012 10:32:22 PM UTC+2, kimchy wrote:
First, you don't need to store the field. Second, by default, when the
lat_lon are not indexed, the values are loaded to memory and used for geo
calculations in memory (like checking bounding boxes, distances and the
like). For things that can use lat_lon that are indexed (like bounding
boxes), then you can configure the relevant geo filter to the the "checks"
instead of in memory, using the indexed lat_lon. Most times, the in memory
option is the one you want.
There's very little information about the geopoint "lat_lon"
indexation option.
Can someone describe how queries are leveraging so that I can get a
better understanding of whether that would be helpful in my case?
there's also little information on how to pass an option to the
geopoint mapping is this:
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.