On Wed, Apr 6, 2011 at 9:30 AM, Grant Ingersoll
grant.ingers...@gmail.com wrote:
By all means go for it. I don't see any reason not too. I guess in the end,
I'm not sure what you are asking us to do. Do you want Lucene/Solr to remove
all of our spatial support in favor of incorporating
The spatial API in google code takes a pretty different approach to
spatial search in general. It is organized into three key packages:
1. core stuff, no lucene dependencies. Most of the math is here
Aren't you just replicating what SIS is doing for this piece? If you don't
have a JTS
On Apr 6, 2011, at 10:45 AM, Ryan McKinley wrote:
I'm trying to have an open discussion about what makes sense for
spatial development. I don't *want* to start a new project... but I
think we need a dev/test environment that can support the whole range
of spatial needs -- without reinventing
On Apr 6, 2011, at 11:38 AM, Grant Ingersoll wrote:
Until there is a specific patch that brings in and shows how JTS would be
incorporated (via reflection and as a totally optional piece, presumably, per
the ASF LGPL guidelines), there really isn't anything to vote on.
I think what is being
-1. I *totally* understand if other people don't want JTS in the
build system -- it is not a core concern to most people involved.
Until there is a specific patch that brings in and shows how JTS would be
incorporated (via reflection and as a totally optional piece, presumably, per
the
On Apr 6, 2011, at 12:06 PM, Smiley, David W. wrote:
On Apr 6, 2011, at 11:38 AM, Grant Ingersoll wrote:
Until there is a specific patch that brings in and shows how JTS would be
incorporated (via reflection and as a totally optional piece, presumably,
per the ASF LGPL guidelines), there
On Apr 6, 2011, at 2:08 PM, Grant Ingersoll wrote:
with its replacement being an externally hosted ASL-licened module expressly
designed to work with Lucene/Solr 4.0 and beyond (temporarily known as
lucene-spatial-playground). What would stay is the _basic_ spatial support
that got into
On Wed, Apr 6, 2011 at 2:08 PM, Grant Ingersoll
grant.ingers...@gmail.com wrote:
On Apr 6, 2011, at 12:06 PM, Smiley, David W. wrote:
with its replacement being an externally hosted ASL-licened module expressly
designed to work with Lucene/Solr 4.0 and beyond (temporarily known as
Right - there's no need to try and make promises about the future. It
seems unrelated to the questions at hand here.
To be clear... I don't see any of this as promises -- obviously
nothing happens until there is somethign concrete to evaluate.
The point of this thread (for me anyway) is to
On Apr 3, 2011, at 3:50 PM, Ryan McKinley wrote:
In the days of sub-projects, I would have proposed that option, but
now I see two options:
A. Work on spatial lucene outside of apache -- perhaps osgeo or even
just github. (would need a different name)
B. Allow JTS compile-time
On Tue, Apr 5, 2011 at 9:34 AM, Grant Ingersoll gsing...@apache.org wrote:
On Apr 3, 2011, at 3:50 PM, Ryan McKinley wrote:
In the days of sub-projects, I would have proposed that option, but
now I see two options:
A. Work on spatial lucene outside of apache -- perhaps osgeo or even
just
doubles (LatLonPoint) and a distance functionquery. If you
consider that, then why would it be in Lucene/Solr?
~ David
From: Grant Ingersoll [gsing...@apache.org]
Sent: Tuesday, April 05, 2011 9:34 AM
To: dev@lucene.apache.org
Subject: Re: Lucene Spatial Future
]
Sent: Tuesday, April 05, 2011 9:34 AM
To: dev@lucene.apache.org
Subject: Re: Lucene Spatial Future
On Apr 3, 2011, at 3:50 PM, Ryan McKinley wrote:
In the days of sub-projects, I would have proposed that option, but
now I see two options:
A. Work on spatial lucene outside of apache
, 2011 11:23 AM
To: dev@lucene.apache.org
Cc: Smiley, David W.
Subject: Re: Lucene Spatial Future
Forgive my ignorance, but: are there any technical reasons for spatial
work to be in core?
Or can all the spatial algos be safely (ie, won't lose much
performance, if any) built on top of Lucene's
On Tue, Apr 5, 2011 at 11:23 AM, Michael McCandless
luc...@mikemccandless.com wrote:
Forgive my ignorance, but: are there any technical reasons for spatial
work to be in core?
There is no reason it needs to be in core.
As is, it is a maven build that depends on -SNAPSHOT and everything works
Grant, since you too have an interest in spatial, you too could be a
developer on lucene-spatial-playground (I look forward to a better name).
Just because there are folks interested in spatial involved with Lucene/Solr
does not mean that the module needs to actually be in the
On Apr 3, 2011, at 3:50 PM, Ryan McKinley wrote:
If we do elect for option A, I would also suggest we delete the
spatial contrib (in 4.0) and have solr depend on the external .jar --
this way lucene users would have what they need directly with the
external .jar, and solr users would get lots
Let's just do it in Solr directly. I like the jar idea for JTS.
We just need more committers to contribute and support the people
doing the work.
Bill
On Tue, Apr 5, 2011 at 2:46 PM, Grant Ingersoll gsing...@apache.org wrote:
On Apr 3, 2011, at 3:50 PM, Ryan McKinley wrote:
If we do elect
On Tue, Apr 5, 2011 at 2:46 PM, Grant Ingersoll gsing...@apache.org wrote:
On Apr 3, 2011, at 3:50 PM, Ryan McKinley wrote:
If we do elect for option A, I would also suggest we delete the
spatial contrib (in 4.0) and have solr depend on the external .jar --
this way lucene users would have
Hi,
On Wed, Apr 6, 2011 at 6:46 AM, Grant Ingersoll gsing...@apache.org wrote:
On Apr 3, 2011, at 3:50 PM, Ryan McKinley wrote:
If we do elect for option A, I would also suggest we delete the
spatial contrib (in 4.0) and have solr depend on the external .jar --
this way lucene users
On Apr 3, 2011, at 3:50 PM, Ryan McKinley wrote:
In the days of sub-projects, I would have proposed that option, but
now I see two options:
A. Work on spatial lucene outside of apache -- perhaps osgeo or even
just github. (would need a different name)
B. Allow JTS compile-time dependency
Hello-
I think it is worth discussing what we want to do with the lucene
spatial contrib.
If you have followed the spatial development, it started with a large
contribution and has never had much love or attention. Grant did some
great work to get point search working in solr, but much of the
Hi Ryan,
On Apr 3, 2011, at 12:50 PM, Ryan McKinley wrote:
2. 3rd party tools -- In general people working on complex geographic
problems use JTS and other LGPL tools. There is some great work
happening at Apache SIS now, but it is a long way from being a viable
ASL alternative.
Thanks
23 matches
Mail list logo
