o:* dev@lucene.apache.org
>>
>> *Subject:* Re: [DISCUSS] Geo/spatial organization in Lucene
>> +1 to move LatLonPoint and friends to core, and nuke the spatial module
>>
>> On 25 Jun 2018, at 16:32, David Smiley wrote:
>>
>> Okay fine, I'm not going
+1
On Mon, Jun 25, 2018, 11:32 AM Ignacio Vera Sequeiros wrote:
> +1
> --
> *From:* Alan Woodward
> *Sent:* Monday, June 25, 2018 5:56:16 PM
> *To:* dev@lucene.apache.org
>
> *Subject:* Re: [DISCUSS] Geo/spatial organization in Lucene
>
+1
From: Alan Woodward
Sent: Monday, June 25, 2018 5:56:16 PM
To: dev@lucene.apache.org
Subject: Re: [DISCUSS] Geo/spatial organization in Lucene
+1 to move LatLonPoint and friends to core, and nuke the spatial module
On 25 Jun 2018, at 16:32, David Smiley
+1 to move LatLonPoint and friends to core, and nuke the spatial module
> On 25 Jun 2018, at 16:32, David Smiley wrote:
>
> Okay fine, I'm not going to block spatial stuff going into core.
> (celebration). I foresee the spatial stuff there growing beyond the one
> default impl though.
>
>
Okay fine, I'm not going to block spatial stuff going into core.
(celebration). I foresee the spatial stuff there growing beyond the one
default impl though.
Perhaps most of us are still not happy with seeing spatial code across so
many modules? Nick and I have voiced this concern so far.
I also favor B: move the common case, good performing spatial
implementations to core, but still bake new things in sandbox. LatLonPoint
has baked way too long already! The addition of first class (codec
support) KD trees in Lucene (dimensional points) was/is really a game
changer for Lucene
is in the core together with the planar implementation.
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From:* Karl Wright [mailto:daddy...@gmail.com]
> *Sent:* Monday, June 25, 2018 12:38 PM
> *To:* Lucene/Solr dev
> *Subject:* Re: [DISCUSS] Geo/spatial
[mailto:daddy...@gmail.com]
Sent: Monday, June 25, 2018 12:38 PM
To: Lucene/Solr dev
Subject: Re: [DISCUSS] Geo/spatial organization in Lucene
' One final note, the geo3d universe contains references to the planar universe'
Can you clarify? Where are these references?
Karl
On Mon, Jun 25, 2018 at 4:25 AM
o the planar
> universe. That only make sense if those shapes are generic and are in core.
>
>
>
> Ignacio
>
>
>
>
>
>
>
>
>
> *From:* Karl Wright [mailto:daddy...@gmail.com]
> *Sent:* Sunday, June 24, 2018 7:10 AM
> *To:* Lucene/Solr dev
contains references to the planar universe.
That only make sense if those shapes are generic and are in core.
Ignacio
From: Karl Wright [mailto:daddy...@gmail.com]
Sent: Sunday, June 24, 2018 7:10 AM
To: Lucene/Solr dev
Subject: Re: [DISCUSS] Geo/spatial organization in Lucene
Data points:
(1
Data points:
(1) For both geo3d and Robert's implementation (at least!) there exists a
public API already. For geo3d, this consists of:
drwxrwxrwx 0 root root 512 Jun 19 02:47 geom
-rwxrwxrwx 1 root root 5586 Jun 19 02:47 PointInGeo3DShapeQuery.java
-rwxrwxrwx 1 root root 4940 Jun 19 02:47
Hi David.
I'm not arguing for or against anything in particular. I was simply
communicating the state of things as I saw today. And yes, we have spatial
code in five modules; and yes, that's pretty crazy. I was originally of the
"keep it simple" opinion that all spatial should live in either the
Sorry, I just returned from an overseas trip. I'll try to put some thought
into a cogent response when I get a little less scrambled.
Karl
On Fri, Jun 22, 2018 at 4:16 PM David Smiley
wrote:
> Nick, are you not only arguing for spatial code to be in Lucene core, but
> also for the "spatial"
Nick, are you not only arguing for spatial code to be in Lucene core, but
also for the "spatial" module to continue to exist? And I believe Adrien
still wants some spatial stuff in sandbox so that means spatial code in 5
modules. Five modules... let that that sink in... wow. Gosh that's kinda
Maybe it should be spatial2D vs. spatial3D then? To avoid sounding
that spatial3D is a child of spatial.
Regards,
Alex.
On 22 June 2018 at 05:41, Karl Wright wrote:
> The abstractions in spatial3d are not the same abstractions as you find in
> spatial, and yet they sound similar. So I'd
The abstractions in spatial3d are not the same abstractions as you find in
spatial, and yet they sound similar. So I'd worry that if we threw them
together we'd be setting ourselves up for a shotgun marriage at some
point. I would strongly disagree that that was in any way a good idea.
The
I don’t normally speak up on spatial issues because I don’t know anything about
spatial stuff, but I suppose a point of view from somebody outside the code may
be helpful, so…
I think I’d lean towards B. Having the 99% case in core makes most sense to me,
and it means that we can add some
If I were to pick between the two, I also have a preference for B. I've
also tried to keep this whole spatial organization rather simple:
core - simple spatial capabilities needed by the 99% spatial use case
(e.g., web mapping). Includes LatLonPoint, polygon & distance search
(everything
I have a slight preference for B similarly to how StandardAnalyzer is in
core and other analyzers are in analysis, but no strong feelings. In any
case I agree that both A and B would be much better than the current
situation.
Le mer. 20 juin 2018 à 18:09, David Smiley a
écrit :
> I think
I think everyone agrees the current state of spatial code organization in
Lucene is not desirable. We have a spatial module that has almost nothing
in it, we have mature spatial code in the sandbox that needs to "graduate"
somewhere, and we've got a handful of geo utilities in Lucene core (mostly
20 matches
Mail list logo
