[ 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