CRS features in recent ES development.
My fault.
Uwe
Am June 4, 2020 1:40:51 PM UTC schrieb Uwe Schindler :
>Hi,
>
>Yes. With different projections there is one issue: Elasticsearch only
>converts the polygon points to wgs84. But depending on the projection,
>the lines between
Hi,
Yes. With different projections there is one issue: Elasticsearch only converts
the polygon points to wgs84. But depending on the projection, the lines between
the points may have a different shape in reality (no longer lines, but maybe
curves), but as only the line endpoints are converted
Thanks for the help! This isn't very clear in the Elasticsearch docs. Upon
converting to WGS-84 everything seems to index fine.
Van: Ignacio Vera
Verzonden: donderdag 4 juni 2020 14:01
Aan: java-user@lucene.apache.org
Onderwerp: Re: Tessellate excepti
I think this is not a lucene issue. Elasticsearch geo_shape only supports
(and it assumes) polygons on the WGS-84 reference system.
On Thu, Jun 4, 2020 at 1:38 PM Claeys Wouter
wrote:
> Hi,
>
> This is the original polygon:
>
> {
>"crs":{
> &qu
71044.231002,
175818.094268
]
]
]
]
}
Thanks!
Van: Ignacio Vera Sequeiros
Verzonden: donderdag 4 juni 2020 12:24
Aan: java-user@lucene.apache.org
Onderwerp: Re: Tessellate exception in Elasticsearch
Hi,
I think your polygon has i
Hi,
I think your polygon has intersecting edges but it is difficult to
reproduce with that output. Could you provide the original polygon you are
trying to index?
Thanks!
On Thu, Jun 4, 2020 at 11:30 AM Claeys Wouter
wrote:
> Hi,
>
> This is an error which we get in Elasticsearch wh
Hi,
This is an error which we get in Elasticsearch when trying to index geo_shape
fields but it seems this can be narrowed down to a problem in Lucene. We can
reproduce the problem withe ES 6.8.x and ES 7.7.x. This is the error we are
getting:
Caused by: java.lang.IllegalArgumentException
Hi Alicia,
I do not know it will help but I answer.
The query will search the *"Term"* in the Index.
When developer uses Elasticsearch first time, they confuse Full text
queries with Term level queries much.
These two are very different.
Please check.
Full text queries :
https://www.
Hi Alica,
You might want to ask your question at the Elasticsearch mailing list (
http://discuss.elastic.co) or at Magento's (https://community.magento.com/).
Because Lucene is really just a library, with an very open-ended way of
doing document scoring that could mix in any number of wa
ranked against the Index.
I found a document that stated that ElasticSearch uses Lucene to perfom its
scoring logic.
We are extremely keen on fixing currently search logic! Are you able to please
provide me with any CLEAR documentation on how search querys are match against
the index and then
.com>;
> 发送时间: 2018年6月5日(星期二) 晚上6:50
> 收件人: "java-user";
>
> 主题: can anybody give some suggest about this elasticsearch shard failed
> problem? thanks
>
>
>
>
> Elasticsearch version (bin/elasticsearch --version): 5.1.1
>
> Plugins installed: [] no
>
Elasticsearch version (bin/elasticsearch --version): 5.1.1
Plugins installed: [] no
JVM version (java -version): 1.8.0_77
OS version (uname -a if on a Unix-like system): CentOS Linux release 7.2.1511
(Core)
Description of the problem including expected versus actual behavior:
when using
;;
: can anybody give some suggest about this elasticsearch shard failed
problem? thanks
Elasticsearch version (bin/elasticsearch --version): 5.1.1
Plugins installed: [] no
JVM version (java -version): 1.8.0_77
OS version (uname -a if on a Unix-like system): CentOS Linux release 7.2.1511
(Co
Thank you all for the feedback and your point of views.
Peyman
On Nov 18, 2011, at 2:47 AM, Peter Karich wrote:
> Hi Lukáš, hi Mark
>
>> https://issues.apache.org/jira/browse/SOLR-839
>
>
> thanks for pointing me there
>
>
>>> although some parameters are available as URL parameters as w
Hi Lukáš, hi Mark
> https://issues.apache.org/jira/browse/SOLR-839
thanks for pointing me there
> > although some parameters are available as URL parameters as well in ES
> Not sure if I understood exactly what you meant here but do you know you
> can always use "source" URL parameter to p
,
> which makes it hard to parse for *non*-humans and sub-intelligent people
> IMO. An advantage is that you can put the URL into the browser with
> Solr, which is only possible via additional software for ES (called
> Elasticsearch-head). although some parameters are available as U
for
> ranges, local params, term filter, ...),
> which makes it hard to parse for *non*-humans and sub-intelligent people
> IMO. An advantage is that you can put the URL into the browser with
> Solr, which is only possible via additional software for ES (called
> Elasticsearch-head)
ich is only possible via additional software for ES (called
Elasticsearch-head). although some parameters are available as URL
parameters as well in ES
Regards,
Peter.
> On Thu, Nov 17, 2011 at 3:44 PM, Michael McCandless
> wrote:
>> Maybe someone can post the equivalent query in E
: > Maybe someone can post the equivalent query in ElasticSearch?
:
: I don't think it's possible. Hoss threw in the kitchen sink into his
: "contrived' example.
exactly ... i have no idea if that type of query is possible with ES, but
it was not intended to be an exam
>
> Other parameters such as filters, faceting, highlighting, sorting,
> etc, don't normally have any hierarchy.
I regularly mix filters and queries inside Boolean logic. Attempts to structure
data (e.g. geocoding) don't always achieve 100% coverage and so for better
recall you must also resor
On Thu, Nov 17, 2011 at 3:44 PM, Michael McCandless
wrote:
> Maybe someone can post the equivalent query in ElasticSearch?
I don't think it's possible. Hoss threw in the kitchen sink into his
"contrived' example.
Here's a super simple example:
JSON:
{
"so
On Thu, Nov 17, 2011 at 3:40 PM, Mark Harwood wrote:
> JSON or XML can reflect more closely the hierarchy in the underlying Lucene
> query objects.
We normally use the Lucene QueryParser syntax itself for that (not
HTTP parameters).
Other parameters such as filters, faceting, highlighting, sort
Maybe someone can post the equivalent query in ElasticSearch? Then at
least we have a fair comparison of the two syntaxes, for this one
(complex) query at least...
Mike McCandless
http://blog.mikemccandless.com
On Thu, Nov 17, 2011 at 3:21 PM, Yonik Seeley
wrote:
> On Thu, Nov 17, 2011 a
I don't think of queries as inherently flat in the way HTTP request parameters
are with their name=value pairings.
JSON or XML can reflect more closely the hierarchy in the underlying Lucene
query objects.
For me using a "flat" query interface feels a bit like when you start off
trying to manag
On Thu, Nov 17, 2011 at 3:18 PM, Uwe Schindler wrote:
> Sorry, this query is really ununderstandable. Those complex queries should
> have a meaningful language, e.g. a JSON object structure
There are upsides and downsides to that. A big JSON object graph
would be easier to *read* but certainly n
> Or if you're just unjustifiably bitching about Solr again
Sorry, this query is really ununderstandable. Those complex queries should
have a meaningful language, e.g. a JSON object structure (like
XMLQueryParser, but instead JSON). Those queries are never entered by users
only by machines, why no
On Thu, Nov 17, 2011 at 8:03 PM, Yonik Seeley
wrote:
> On Thu, Nov 17, 2011 at 2:53 PM, Simon Willnauer
> wrote:
>> dude, look at this query... its insane isn't it :)
>
> Sorry... what's the equivalent you'd like instead?
oh, I think there are many ways to design a DSL for querying..
something I
On Nov 17, 2011, at 9:03 PM, Yonik Seeley wrote:
>> dude, look at this query... its insane isn't it :)
>
> Sorry... what's the equivalent you'd like instead?
> Or if you're just unjustifiably bitching about Solr again, maybe I
> should take a stroll through Lucene land and bitch about
> incompre
On Thu, Nov 17, 2011 at 2:53 PM, Simon Willnauer
wrote:
> dude, look at this query... its insane isn't it :)
Sorry... what's the equivalent you'd like instead?
Or if you're just unjustifiably bitching about Solr again, maybe I
should take a stroll through Lucene land and bitch about
incomprehensi
&fq={!term f=$ff v=$vv}&ff=keywords&vv=solr
>>> &sort=query(keywords:lame) asc, score desc
>>>
>> I agree, one big difference here is that I might spend 2h reading &
>> finding documentat
desc
>>
> I agree, one big difference here is that I might spend 2h reading &
> finding documentation to figure out what that does :D
>
> simon
Did you mean the ElasticSearch or the Solr part ;) !! ;)
Peter.
--
http://jetsli.de news reader for geeks
---
On Wed, Nov 16, 2011 at 10:18 PM, Chris Hostetter
wrote:
>
> : "Think of the Query DSL as an AST of queries"
> : http://www.elasticsearch.org/guide/reference/query-dsl/
>
> I'm not familiar with ES, but FWIW: based on that one page the "Query DSL"
> doesn't really sound much more powerful then wha
: "Think of the Query DSL as an AST of queries"
: http://www.elasticsearch.org/guide/reference/query-dsl/
I'm not familiar with ES, but FWIW: based on that one page the "Query DSL"
doesn't really sound much more powerful then what you can do with nested
queries, local params, and param refs usin
The docs are slim on examples.
On Wed, Nov 16, 2011 at 3:35 PM, Peter Karich wrote:
>
>>> even high complexity as ES supports lucene-like query nesting via JSON
>> That sounds interesting. Where is it described in the ES docs? Thanks.
>
> "Think of the Query DSL as an AST of queries"
> http://w
>> even high complexity as ES supports lucene-like query nesting via JSON
> That sounds interesting. Where is it described in the ES docs? Thanks.
"Think of the Query DSL as an AST of queries"
http://www.elasticsearch.org/guide/reference/query-dsl/
For further info ask on ES mailing list.
Reg
> even high complexity as ES supports lucene-like query nesting via JSON
That sounds interesting. Where is it described in the ES docs? Thanks.
On Wed, Nov 16, 2011 at 1:36 PM, Peter Karich wrote:
> Hi,
>
> its not really fair to compare NRT of Solr to ElasticSearch.
> Elastic
Hi,
its not really fair to compare NRT of Solr to ElasticSearch.
ElasticSearch provides NRT for distributed indices as well... also when
doing heavy indexing Solr lacks real NRT.
The only main disadvantages of ElasticSearch are:
* only one (main) committer
* no autowarming
> the ES team
On Wed, Nov 16, 2011 at 10:36 AM, Shashi Kant wrote:
> I had posted this earlier on this list, hope this provides some answers
>
> http://engineering.socialcast.com/2011/05/realtime-search-solr-vs-elasticsearch/
Except it's an out of date comparison.
We have NRT (near real time s
I had posted this earlier on this list, hope this provides some answers
http://engineering.socialcast.com/2011/05/realtime-search-solr-vs-elasticsearch/
On Wed, Nov 16, 2011 at 9:53 AM, Federico Fissore wrote:
> Peyman Faratin, il 16/11/2011 15:12, ha scritto:
>
> Hi
>>
Peyman Faratin, il 16/11/2011 15:12, ha scritto:
Hi
A client is considering moving from Lucene to ElasticSearch. What is the
community's opinion on ES?
thank you
we have recently compared ES to Solr to estimate the effort of evolving
our search infrastructure (it was game like: two
Under the covers, ElasticSearch contains mutliple lucene indexes -- so the
full expressiveness of lucene queries are translatable to ElasticSearch --
but the benefit of using ES as an abstraction layer to give sharded
searches is something attractive enough that we're looking at it too. ;
Hi
A client is considering moving from Lucene to ElasticSearch. What is the
community's opinion on ES?
thank you
Peyman
-
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail:
Hi,
Just wanted to announce the release of a new open source project called
ElasticSearch (http://www.elasticsearch.com/). Its an open source (Apache
2), distributed, search engine built on top of Lucene. There are many
features for ElasticSearch, you can find them here:
http
43 matches
Mail list logo
