[
https://issues.apache.org/jira/browse/LUCENE-7381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-7381:
-----------------------------------
Attachment: LUCENE-7381.patch
Thanks [~jpountz]!
bq. Should the field be called something like DoubleRange
+1. I was on the fence about this but I think its the right way to go. Not only
does it make it sense for consistency but it reduces index size for ints and
floats.
bq. The reuse of fieldsData in setRangeValues worries me a bit, is it safe?
We did this in {{LatLonPoint}}. I don't think its any less safe than creating a
new BytesRef (but more efficient?) Maybe [~mikemccand] has a better answer?
bq. QueryType does not need to be public?
+1
bq. Why do you replace infinities with +/-MAX_VALUE?
Good catch, I think that was in there from unrelated debugging funzies.
Updated patch is attached.
> Add new RangeField
> ------------------
>
> Key: LUCENE-7381
> URL: https://issues.apache.org/jira/browse/LUCENE-7381
> Project: Lucene - Core
> Issue Type: New Feature
> Reporter: Nicholas Knize
> Attachments: LUCENE-7381.patch, LUCENE-7381.patch, LUCENE-7381.patch,
> LUCENE-7381.patch
>
>
> I've been tinkering with a new Point-based {{RangeField}} for indexing
> numeric ranges that could be useful for a number of applications.
> For example, a single dimension represents a span along a single axis such as
> indexing calendar entries start and end time, 2d range could represent
> bounding boxes for geometric applications (e.g., supporting Point based geo
> shapes), 3d ranges bounding cubes for 3d geometric applications (collision
> detection, 3d geospatial), and 4d ranges for space time applications. I'm
> sure there's applicability for 5d+ ranges but a first incarnation should
> likely limit for performance.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
