lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicholas Knize (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LUCENE-7056) Spatial3d/Geo3d should have zero runtime dependencies
Date Thu, 03 Mar 2016 05:13:18 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-7056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15177188#comment-15177188
] 

Nicholas Knize commented on LUCENE-7056:
----------------------------------------

bq. we want to not have all of spatial3d/geo3d piled in one package, so lets just start with
that?

+1 This would be a wonderful improvement. 

I'm also not a fan of the name *3d. It causes confusion that this package handles altitude.
Since its dependency free I still think it makes most sense to refactor it to the spatial
module under a geometry package and just have the spatial and spatial-extras modules. Having
a third just for a geometry model doesn't make sense to me. 

Of course, longer term, we should simplify the geom portion of the Geo API so the users don't
care what the underlying geometry model is. That should be dictated by chosen datum/projection
once we have support in place. 

> Spatial3d/Geo3d should have zero runtime dependencies
> -----------------------------------------------------
>
>                 Key: LUCENE-7056
>                 URL: https://issues.apache.org/jira/browse/LUCENE-7056
>             Project: Lucene - Core
>          Issue Type: Improvement
>          Components: modules/spatial3d
>            Reporter: David Smiley
>            Assignee: David Smiley
>             Fix For: 6.0
>
>
> This is a proposal for the "spatial3d" module to be purely about the shape/geometry implementations
it has.  In Lucene 5 that's actually all it has.  In Lucene 6 at the moment its ~76 files
have 2 classes that I think should go elsewhere: Geo3DPoint and PointInGeo3DShapeQuery.  Specifically
lucene-spatial-extras (which doesn't quite exist yet so lucene-spatial) would be a suitable
place due to the dependency.   _Eventually_ I see this module migrating elsewhere be it on
its own or a part of something else more spatial-ish.  Even if that never comes to pass, non-Lucene
users who want to use this module for it's geometry annoyingly have to exclude the Lucene
dependencies that are there because this module also contains these two classes.
> In a comment I'll suggest some specifics.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message