[
https://issues.apache.org/jira/browse/LUCENE-8369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16893187#comment-16893187
]
Michael McCandless commented on LUCENE-8369:
--------------------------------------------
{quote}Lots of awesome functionality _commonly_ needed in search is in our
modules – like highlighting, autocomplete, and spellcheck, to name a few. Why
should spatial be an exception?
{quote}
Well, other examples are default analysis ({{StandardAnalyzer}}), common
queries (versus exotic queries in the queries module), most {{Directory}}
implementations, where we have some common choices in core and more exotic
choices in our modules.
I think it (the "common" classes and the "exotic" ones) is a helpful
distinction for our users for areas that have many many options.
[~nknize] can you give a concrete example where the code sharing is making
things difficult? Can we simply make the necessary APIs public and marked
{{@lucene.internal}} in our core spatial classes?
> Remove the spatial module as it is obsolete
> -------------------------------------------
>
> Key: LUCENE-8369
> URL: https://issues.apache.org/jira/browse/LUCENE-8369
> Project: Lucene - Core
> Issue Type: Task
> Components: modules/spatial
> Reporter: David Smiley
> Assignee: David Smiley
> Priority: Major
> Attachments: LUCENE-8369.patch
>
>
> The "spatial" module is at this juncture nearly empty with only a couple
> utilities that aren't used by anything in the entire codebase --
> GeoRelationUtils, and MortonEncoder. Perhaps it should have been removed
> earlier in LUCENE-7664 which was the removal of GeoPointField which was
> essentially why the module existed. Better late than never.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
