[GitHub] [lucene] nknize commented on issue #11702: Multi-Value Support for Binary DocValues [LUCENE-10666]

[GitBox <gi...@apache.org>]

nknize commented on issue #11702:
URL: https://github.com/apache/lucene/issues/11702#issuecomment-1309269456

   > because in the real world objects can only exist in one place a a time.
   
   Except in geo search / analysis this depends on [spatial resolution](https://en.wikipedia.org/wiki/Spatial_resolution) of the source data; real world geo data is not precise and often ends up with multiple documents in the same location. Clearly (not through a hack) supporting these use cases  along with supporting coverage areas as a multi geometry shape only makes Lucene stronger. I don't think there's anything wrong w/ supporting standards like [RFC 7946](https://www.rfc-editor.org/rfc/rfc7946) in our encoding.
   
   > This is why i hate all multi-valued docvalues, because its always so ambiguous. If i have 3 locations for the doc and i'm sorting by distance, which one should i use? etc etc.
   
   It depends on spatial resolution. Besides, we support these use cases already, we don't support the multi-shape use case above without an unnecessarily bloated hackey encoding.
   
   > If someone wants to encode multiple values into a binary docvalues, nothing is stopping them. they can encode integer/byte length up front, do a vint-like encoding, whatever they want.
   
   It's software, yes. Nothing is also stopping anyone from encoding the bible and calling it a geo_shape. 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


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