Nick Knize

> Maybe we should make the ctor that takes a `BytesRef` public for such use-cases? We can either make the `LatLonShapeDocValues` and `XYShapeDocValues` ctor public, or add new factory methods...

> Plus I believe this is good as it provides 1 single class with different interfaces to work with LatLonShape or LatLonShapeDocValues. I agree. That was the intent of the...

16days since my review. If there are no concerns in the next 24 hrs I'll merge.

> ... and make the constructor private. It makes no-sense to have them in LatLonShape / XYShape. The ctor is already protected. It does make sense in that LatLonShape and...

> I strongly believe that LatLonShape /XYShape should only contain factory methods that work on top of the BKD tree index I see what you're saying, and I really like...

If we can't think of anything quickly I think a good compromise would be to merge this long running PR so @navneet1v can use the field until we figure out...

> once you create a ShapeDocValues, you don't know if is geo or cartesian because the specific implementations are hidden from the user I'm not following what you mean by...

There's no automation for that. Just check out `branch_9x` and cherry-pick the commit and open a backport PR.

More context is needed here. Direct memory (mmaped files) is subject to swapping. Was this tested w/ swapping enabled (which can seriously impact a nodes performance) or disabled? e.g.,: 1....

> In some cases this can cause the BKDReader to consume more CPU cycles and increase request latency Can we get more information on the "some cases"? The flamegraph is...