Solr
  1. Solr
  2. SOLR-7005

facet.heatmap for spatial heatmap faceting on RPT

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 5.1
    • Component/s: spatial
    • Labels:
      None

      Description

      This is a new feature that uses the new spatial Heatmap / 2D PrefixTree cell counter in Lucene spatial LUCENE-6191. This is a form of faceting, and as-such I think it should live in the "facet" parameter namespace. Here's what the parameters are:

      • facet=true
      • facet.heatmap=fieldname
      • facet.heatmap.geom=["-180 -90" TO "180 90"]
      • facet.heatmap.gridLevel=6
      • facet.heatmap.distErrPct=0.15
      • facet.heatmap.format=ints2D | png
        (Officially see FacetParams where options are documented)

      Like other faceting features, the fieldName can have local-params to exclude filter queries or specify an output key. This could be quite useful in doing difference faceting on the same spatial data to identify relative change against a baseline.

      The geom is optional; you get the whole world or you can specify a box or WKT.

      Ultimately, this feature needs to know the grid level, which together with the input shape will yield a certain number of cells. You can specify gridLevel exactly, or don't and instead provide distErrPct which is computed like it is for the RPT field type as seen in the schema. 0.10 yielded ~4k cells but it'll vary. There's also a facet.heatmap.maxCells safety net defaulting to 100k. Exceed this and you get an error.

      The output is (JSON):

      {gridLevel=6,columns=64,rows=64,minX=-180.0,maxX=180.0,minY=-90.0,maxY=90.0,counts_ints2D=[[0, 0, 2, 1, ....],[1, 1, 3, 2, ...],...]}
      

      counts_ints2D is null if all would be 0. individual row arrays should likewise be null... I welcome feedback.

      If you set the output to 'png' then you get a 4-byte per pixel/cell PNG, or null if all counts are 0. The high byte (alpha channel) is inverted so that counts need to exceed 2^24 before the image will start to fade out if you try and view it.

      This supports sharded / distributed queries.

      1. heatmap_512x256.png
        66 kB
        David Smiley
      2. heatmap_64x32.png
        3 kB
        David Smiley
      3. SOLR-7005_heatmap.patch
        45 kB
        David Smiley
      4. SOLR-7005_heatmap.patch
        44 kB
        David Smiley
      5. SOLR-7005_heatmap.patch
        44 kB
        David Smiley
      6. SOLR-7005_heatmap.patch
        27 kB
        David Smiley

        Issue Links

          Activity

          Hide
          David Smiley added a comment -

          I really don't wan't to weigh down SimpleFacets any more than it is... so I will go the route that interval faceting did and put the code in a separate class and only put a modicum of hooks into FacetComponent and SimpleFacets. As I write this, my working code in-progress is actually a separate SearchComponent that follows FacetComponent; it extends SimpleFacets to use some of its capability. But it seems that if I'm going to use the facet namespace, I ought to hook in directly to FacetComponent; plus users need not register a separate component. As always, I welcome input from other devs.

          p.s. preliminary perf #'s are super promising. Real numbers will be forthcoming later. I envision real-time time-series heatmap movies being generated and displayed in the browser with thousands of cells of resolution per-frame.

          Show
          David Smiley added a comment - I really don't wan't to weigh down SimpleFacets any more than it is... so I will go the route that interval faceting did and put the code in a separate class and only put a modicum of hooks into FacetComponent and SimpleFacets. As I write this, my working code in-progress is actually a separate SearchComponent that follows FacetComponent; it extends SimpleFacets to use some of its capability. But it seems that if I'm going to use the facet namespace, I ought to hook in directly to FacetComponent; plus users need not register a separate component. As always, I welcome input from other devs. p.s. preliminary perf #'s are super promising. Real numbers will be forthcoming later. I envision real-time time-series heatmap movies being generated and displayed in the browser with thousands of cells of resolution per-frame.
          Hide
          Shalin Shekhar Mangar added a comment -

          I envision real-time time-series heatmap movies being generated and displayed in the browser with thousands of cells of resolution per-frame

          That's super cool!

          Show
          Shalin Shekhar Mangar added a comment - I envision real-time time-series heatmap movies being generated and displayed in the browser with thousands of cells of resolution per-frame That's super cool!
          Hide
          David Smiley added a comment -

          There are some performance #'s on LUCENE-6191.

          I experimented with generating a PNG to carry the data in a compressed manner, since this data can get large. I'm abusing the image to carry the same detail in the counts, and that means 4 bytes per pixel. Counts > 16M touch the high byte of a 4-byte int, which is where the alpha channel is, which will progressively lighten the image. The image is not at all optimized for human viewing that is pleasant on the eyes, except for the bit flip of the high (alpha channel) byte; otherwise you would see nothing until the counts exceed this figure. That said, it's crude and you can get a sense of it. If people have input on how to cheaply and easily tweak the value to look nicer, I'm interested. Since a client app may consume this PNG if it wants this compressed format and render it the way it wants to, there should be a straight-forward algorithm to derive the count from the ARGB (alpha, red, green, blue) int.

          The attached PNG is 512x256 (131,072 cells mind you!) of the 8.5M geonames data set. On a 16 segment index with no search filters, it took 882ms to compute the underlying heatmap, and 218ms to build the PNG and write it to disk. The write-to-disk hack is temporary to easily view the image by opening it from the file system. You can expect there will be more time in consuming this image from Solr's javabin/XML/JSON + base64 wrapper (whatever you choose).

          Now a 512x256 image is so detailed that it arguably isn't a heatmap but another way to go about rendering individual points. A more course, say, 64x32 image would be more true to the heatmap label, and obviously much faster to generate – like 100ms + only ~2ms to generate the PNG.

          Show
          David Smiley added a comment - There are some performance #'s on LUCENE-6191 . I experimented with generating a PNG to carry the data in a compressed manner, since this data can get large. I'm abusing the image to carry the same detail in the counts, and that means 4 bytes per pixel. Counts > 16M touch the high byte of a 4-byte int, which is where the alpha channel is, which will progressively lighten the image. The image is not at all optimized for human viewing that is pleasant on the eyes , except for the bit flip of the high (alpha channel) byte; otherwise you would see nothing until the counts exceed this figure. That said, it's crude and you can get a sense of it. If people have input on how to cheaply and easily tweak the value to look nicer, I'm interested. Since a client app may consume this PNG if it wants this compressed format and render it the way it wants to, there should be a straight-forward algorithm to derive the count from the ARGB (alpha, red, green, blue) int. The attached PNG is 512x256 (131,072 cells mind you!) of the 8.5M geonames data set. On a 16 segment index with no search filters, it took 882ms to compute the underlying heatmap, and 218ms to build the PNG and write it to disk. The write-to-disk hack is temporary to easily view the image by opening it from the file system. You can expect there will be more time in consuming this image from Solr's javabin/XML/JSON + base64 wrapper (whatever you choose). Now a 512x256 image is so detailed that it arguably isn't a heatmap but another way to go about rendering individual points. A more course, say, 64x32 image would be more true to the heatmap label, and obviously much faster to generate – like 100ms + only ~2ms to generate the PNG.
          Hide
          David Smiley added a comment -

          Thanks for the encouragement Shalin, and Erik on #lucene-dev, and others via email who have gotten wind of this.

          Here's the first-draft patch. It is still based on being its own SearchComponent, and it doesn't yet support distributed-search – those issues should be addressed next.

          I added support for the "distErr" parameter to facilitate computing the grid level in the same fashion as used by Lucene spatial to ultimately derive a grid level for a given shape (a rect/box in this case). In fact it re-uses utility methods in Lucene spatial to compute the grid level given the world boundary, distErr (if provided) and distErrPct (if provided). The units of distErr is the same as distanceUnits attribute on the field type (a new Solr 5 thing). So if units is a kilometer and distErr is 100 then the grid cells returns are at least as precise as 100 kilometers (which BTW is a little less than a spherical degree for Earth, which is 111.2km). The 512x256 heatmap I uploaded was generated by specifying distErr=111.2. A client could compute a distErr if they instead know how many minimum cells they want in the heatmap. I may bake that formula in and provide a minCells param.

          For distributed-search, I'm thinking the internal shard requests will use PNG since it's compressed, and then the user can get whatever format they asked for. I only want to write the aggregation logic once, not per-format

          As a part of this work I found it useful to add SpatialUtils.parseRectangle which parses the [lowerLeftPoint TO upperRightPoint] format. In another issue I want to re-use this to provide a more Solr-friendly way of indexing a rectangle (for e.g. BBoxField or RPT) or for specifying worldBounds on the field type.

          Even though I don't have distributed-search implemented yet, the test extends BaseDistributedSearchTestCase any way. I dislike the idea of writing two tests that test the same thing (one distributed, one not) when the infrastructure should make it indifferent since it's transparent to input & output I'm testing. Unfortunately, assertQ & friends are hard-coded to use TestHarness which is in turn hard-coded to use an embedded Solr instance. And unfortunately, BaseDistributedSearchTestCase doesn't let me test 0 shards (hey, I haven't implemented that feature yet!). The patch tweaks BaseDistributedSearchTestCase slightly to let me do this.

          Show
          David Smiley added a comment - Thanks for the encouragement Shalin, and Erik on #lucene-dev, and others via email who have gotten wind of this. Here's the first-draft patch. It is still based on being its own SearchComponent, and it doesn't yet support distributed-search – those issues should be addressed next. I added support for the "distErr" parameter to facilitate computing the grid level in the same fashion as used by Lucene spatial to ultimately derive a grid level for a given shape (a rect/box in this case). In fact it re-uses utility methods in Lucene spatial to compute the grid level given the world boundary, distErr (if provided) and distErrPct (if provided). The units of distErr is the same as distanceUnits attribute on the field type (a new Solr 5 thing). So if units is a kilometer and distErr is 100 then the grid cells returns are at least as precise as 100 kilometers (which BTW is a little less than a spherical degree for Earth, which is 111.2km). The 512x256 heatmap I uploaded was generated by specifying distErr=111.2. A client could compute a distErr if they instead know how many minimum cells they want in the heatmap. I may bake that formula in and provide a minCells param. For distributed-search, I'm thinking the internal shard requests will use PNG since it's compressed, and then the user can get whatever format they asked for. I only want to write the aggregation logic once, not per-format As a part of this work I found it useful to add SpatialUtils.parseRectangle which parses the [lowerLeftPoint TO upperRightPoint] format. In another issue I want to re-use this to provide a more Solr-friendly way of indexing a rectangle (for e.g. BBoxField or RPT) or for specifying worldBounds on the field type. Even though I don't have distributed-search implemented yet, the test extends BaseDistributedSearchTestCase any way. I dislike the idea of writing two tests that test the same thing (one distributed, one not) when the infrastructure should make it indifferent since it's transparent to input & output I'm testing. Unfortunately, assertQ & friends are hard-coded to use TestHarness which is in turn hard-coded to use an embedded Solr instance. And unfortunately, BaseDistributedSearchTestCase doesn't let me test 0 shards (hey, I haven't implemented that feature yet!). The patch tweaks BaseDistributedSearchTestCase slightly to let me do this.
          Hide
          David Smiley added a comment -

          Oh, facet.heatmap.format=png (or "ints", ints being the default)

          Show
          David Smiley added a comment - Oh, facet.heatmap.format=png (or "ints", ints being the default)
          Hide
          David Smiley added a comment -

          The perf tests on the Lucene issue were of the whole world. For fun I went to a small part of the globe, NYC region, and generated a heatmap PNG, 9.5m per pixel (cell) of 467x467 cells on this 16-segment (unoptimized) index and it only took 44ms (to include returning the base64'ed PNG to the client). For more fun I upped the size to be a huge 2096x2096 (4.4M pixels aka cells, bigger than most people's screens) and it took 521ms. It's sparse though; PNG encoding consumed 90% of the time since it was so large; normally it's a few percent. A spatial filter of the same region shows 1298 docs, so yes its sparse relative to the heatmap/image as a whole. This shows this technique can be used for point-plotting purposes when you might want to plot all the points in a search region without them necessarily being in your top-X search list. That use-case, (high-rez but sparse) suggests a different response format than a grid of ints, such as simply listing point coordinates with counts. Doing that is for another time though.

          Show
          David Smiley added a comment - The perf tests on the Lucene issue were of the whole world. For fun I went to a small part of the globe, NYC region, and generated a heatmap PNG, 9.5m per pixel (cell) of 467x467 cells on this 16-segment (unoptimized) index and it only took 44ms (to include returning the base64'ed PNG to the client). For more fun I upped the size to be a huge 2096x2096 (4.4M pixels aka cells, bigger than most people's screens) and it took 521ms. It's sparse though; PNG encoding consumed 90% of the time since it was so large; normally it's a few percent. A spatial filter of the same region shows 1298 docs, so yes its sparse relative to the heatmap/image as a whole. This shows this technique can be used for point-plotting purposes when you might want to plot all the points in a search region without them necessarily being in your top-X search list. That use-case, (high-rez but sparse) suggests a different response format than a grid of ints, such as simply listing point coordinates with counts. Doing that is for another time though.
          Hide
          David Smiley added a comment -

          This latest patch integrates with the FacetComponent to become a new type of faceting; it's no longer a separate SearchComponent. And this implements distributed/sharding support. The params were added to FacetParams.

          Like interval faceting, the code is kept out of FacetComponent & SimpleFacets but even more so (even the distributed logic), with only one-liner hooks where needed, and only a touch more than that in SimpleFacets. The whole situation could be a lot more elegant with a major refactor of how the faceting code overall is organized, but I have no time these days.

          There are some nocommits:

          • I need to randomized-test round-trip the PNG encoding.
          • the ints format is particularly easy to consume and even eye-ball it to get a sense of the data. As-such I want to orient the numbers to go right-to-left then top-down. And maybe rename to "ints2d". But it isn't particularly compact/efficient, and I already know I want a separate format I'm tentatively calling "skipList" that would list the counts with negative numbers signifying how many zeroes to insert; and then you have to know the column/row order to read it, which would of course be documented. This format would be compact and great for sparse data or small heatmaps. But then would we really need "ints2d"?
          • I'm confused about FacetComponent.distributedProcess() line ~215 (removal of faceting types when distribFieldFacetRefinements != null). Chris Hostetter (Unused) Which faceting types should be removed here; why is it just facet.field and facet.query; maybe the others should too?
          • the facet.heatmap.bbox param actually supports not just the rect-query syntax but WKT as well; which can be convenient but I expect to be atypical. Should 'wkt' be a separate mutually exclusive param? Ugh; param fatigue. Or could it be renamed to 'region' or 'shape' or 'geom'? This reminds me; it could be useful for the underlying Lucene heatmap facet counter to not insist on a rectangular region; why not specify any poly and get counts just for those grid squares. That would make 'bbox' even less appropriate.
          Show
          David Smiley added a comment - This latest patch integrates with the FacetComponent to become a new type of faceting; it's no longer a separate SearchComponent. And this implements distributed/sharding support. The params were added to FacetParams. Like interval faceting, the code is kept out of FacetComponent & SimpleFacets but even more so (even the distributed logic), with only one-liner hooks where needed, and only a touch more than that in SimpleFacets. The whole situation could be a lot more elegant with a major refactor of how the faceting code overall is organized, but I have no time these days. There are some nocommits: I need to randomized-test round-trip the PNG encoding. the ints format is particularly easy to consume and even eye-ball it to get a sense of the data. As-such I want to orient the numbers to go right-to-left then top-down. And maybe rename to "ints2d". But it isn't particularly compact/efficient, and I already know I want a separate format I'm tentatively calling "skipList" that would list the counts with negative numbers signifying how many zeroes to insert; and then you have to know the column/row order to read it, which would of course be documented. This format would be compact and great for sparse data or small heatmaps. But then would we really need "ints2d"? I'm confused about FacetComponent.distributedProcess() line ~215 (removal of faceting types when distribFieldFacetRefinements != null). Chris Hostetter (Unused) Which faceting types should be removed here; why is it just facet.field and facet.query; maybe the others should too? the facet.heatmap.bbox param actually supports not just the rect-query syntax but WKT as well; which can be convenient but I expect to be atypical. Should 'wkt' be a separate mutually exclusive param? Ugh; param fatigue. Or could it be renamed to 'region' or 'shape' or 'geom'? This reminds me; it could be useful for the underlying Lucene heatmap facet counter to not insist on a rectangular region; why not specify any poly and get counts just for those grid squares. That would make 'bbox' even less appropriate.
          Hide
          Hoss Man added a comment -

          I'm confused about FacetComponent.distributedProcess() line ~215 (removal of faceting types when distribFieldFacetRefinements != null). Chris Hostetter Which faceting types should be removed here; why is it just facet.field and facet.query; maybe the others should too?

          I'm confused to. (admitedly i haven't looked at it very hard today)

          I suspect this code is just really old, from the back when only facet.field & facet.query existed. I suspect that at that point in time, the idea was:

          1) remove every the facet.field params, because we're about loop over the ones we know still need refinment and add them
          2) remove any facet.query, because they never need refined

          You'll note that a few lines down ~233 there is a similar block of code relating to facet.pivot & facet.pivot.mincount – aparently for the same reasons as #1 above.

          ...Which faceting types should be removed here; why is it just facet.field and facet.query; maybe the others should too?

          i suspect it's safe/efficient to remove all the facet params up front, and let the various types of faceting re-add the params they need if/when they need refined? ... but i'm not certain about that.

          the thing to do is setup a simple cluster where the field terms are vastly diff between two shards (to force refinement) and then look at what distributed refinement requests are sent to each shard when combining multiple types of faceting – make sure that a facet.field + facet.range + facet.query + facet.pivot + facet.heatmap that requires refinement on the facet.field doesn't unneccessarily re-request the same facet.range + facet.query + facet.pivot + facet.heatmap if they don't also need refinement.

          Show
          Hoss Man added a comment - I'm confused about FacetComponent.distributedProcess() line ~215 (removal of faceting types when distribFieldFacetRefinements != null). Chris Hostetter Which faceting types should be removed here; why is it just facet.field and facet.query; maybe the others should too? I'm confused to. (admitedly i haven't looked at it very hard today) I suspect this code is just really old, from the back when only facet.field & facet.query existed. I suspect that at that point in time, the idea was: 1) remove every the facet.field params, because we're about loop over the ones we know still need refinment and add them 2) remove any facet.query, because they never need refined You'll note that a few lines down ~233 there is a similar block of code relating to facet.pivot & facet.pivot.mincount – aparently for the same reasons as #1 above. ...Which faceting types should be removed here; why is it just facet.field and facet.query; maybe the others should too? i suspect it's safe/efficient to remove all the facet params up front, and let the various types of faceting re-add the params they need if/when they need refined? ... but i'm not certain about that. the thing to do is setup a simple cluster where the field terms are vastly diff between two shards (to force refinement) and then look at what distributed refinement requests are sent to each shard when combining multiple types of faceting – make sure that a facet.field + facet.range + facet.query + facet.pivot + facet.heatmap that requires refinement on the facet.field doesn't unneccessarily re-request the same facet.range + facet.query + facet.pivot + facet.heatmap if they don't also need refinement.
          Hide
          Ryan McKinley added a comment -

          the facet.heatmap.bbox param actually supports not just the rect-query syntax but WKT as well; which can be convenient but I expect to be atypical. Should 'wkt' be a separate mutually exclusive param? Ugh; param fatigue. Or could it be renamed to 'region' or 'shape' or 'geom'? This reminds me; it could be useful for the underlying Lucene heatmap facet counter to not insist on a rectangular region; why not specify any poly and get counts just for those grid squares. That would make 'bbox' even less appropriate.

          What about `facet.heatmap.bounds` the term does not imply the shape (and one would not be surprised if it converts WKT to a rectangle or uses the original shape as a later improvement)

          Show
          Ryan McKinley added a comment - the facet.heatmap.bbox param actually supports not just the rect-query syntax but WKT as well; which can be convenient but I expect to be atypical. Should 'wkt' be a separate mutually exclusive param? Ugh; param fatigue. Or could it be renamed to 'region' or 'shape' or 'geom'? This reminds me; it could be useful for the underlying Lucene heatmap facet counter to not insist on a rectangular region; why not specify any poly and get counts just for those grid squares. That would make 'bbox' even less appropriate. What about `facet.heatmap.bounds` the term does not imply the shape (and one would not be surprised if it converts WKT to a rectangle or uses the original shape as a later improvement)
          Hide
          David Smiley added a comment -

          I like facet.heatmap.bounds a lot. I like facet.heatmap.geom too for it's consistency – planned consistency any way with SOLR-4242 in which I suggested the new param should be 'geom' instead of 'wkt'. I suggested this in the Review Board system but I'll add that to the issue now, where it should be.

          Show
          David Smiley added a comment - I like facet.heatmap.bounds a lot. I like facet.heatmap.geom too for it's consistency – planned consistency any way with SOLR-4242 in which I suggested the new param should be 'geom' instead of 'wkt'. I suggested this in the Review Board system but I'll add that to the issue now, where it should be.
          Hide
          David Smiley added a comment -

          i suspect it's safe/efficient to remove all the facet params up front, and let the various types of faceting re-add the params they need if/when they need refined? ... but i'm not certain about that.

          I suspect that as well. I'll look into finding an existing test that exercises distributed refinement, and then I'll see what happens when I throw in extra types of faceting. I don't want to commit that to whatever test that is but I'll use it as a tool to observe. If we're right, then I'll file an issue as an optimization w/ fix; though arguably it could be considered a performance bug.

          Show
          David Smiley added a comment - i suspect it's safe/efficient to remove all the facet params up front, and let the various types of faceting re-add the params they need if/when they need refined? ... but i'm not certain about that. I suspect that as well. I'll look into finding an existing test that exercises distributed refinement, and then I'll see what happens when I throw in extra types of faceting. I don't want to commit that to whatever test that is but I'll use it as a tool to observe. If we're right, then I'll file an issue as an optimization w/ fix; though arguably it could be considered a performance bug.
          Hide
          David Smiley added a comment -

          Updated patch:

          • format "ints" renamed to "ints2D"
          • ints2D is now by-row, top-down making it more easily interpretable by user/developers – like me when I inspect test output
          • facet.heatmap.geom param rename
          • geom can be any WKT and it filters the underlying data as well.
            • refactored this parsing out to a method in SpatialUtils for wider use
            • tested input circle – 0's at the corners
          • tested PNG round-trip (randomized)

          Only thing left is to figure out what parameters FacetComponent should be setting during refinement so that heatmaps (and interval facets) aren't needlessly computed.

          Nevertheless I'm inclined to commit this Monday and incrementally address optimizing the refinement request.

          Show
          David Smiley added a comment - Updated patch: format "ints" renamed to "ints2D" ints2D is now by-row, top-down making it more easily interpretable by user/developers – like me when I inspect test output facet.heatmap.geom param rename geom can be any WKT and it filters the underlying data as well. refactored this parsing out to a method in SpatialUtils for wider use tested input circle – 0's at the corners tested PNG round-trip (randomized) Only thing left is to figure out what parameters FacetComponent should be setting during refinement so that heatmaps (and interval facets) aren't needlessly computed. Nevertheless I'm inclined to commit this Monday and incrementally address optimizing the refinement request.
          Hide
          ASF subversion and git services added a comment -

          Commit 1658614 from David Smiley in branch 'dev/trunk'
          [ https://svn.apache.org/r1658614 ]

          SOLR-7005: New facet.heatmap on spatial RPT fields

          Show
          ASF subversion and git services added a comment - Commit 1658614 from David Smiley in branch 'dev/trunk' [ https://svn.apache.org/r1658614 ] SOLR-7005 : New facet.heatmap on spatial RPT fields
          Hide
          ASF subversion and git services added a comment -

          Commit 1658617 from David Smiley in branch 'dev/branches/branch_5x'
          [ https://svn.apache.org/r1658617 ]

          SOLR-7005: New facet.heatmap on spatial RPT fields

          Show
          ASF subversion and git services added a comment - Commit 1658617 from David Smiley in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1658617 ] SOLR-7005 : New facet.heatmap on spatial RPT fields
          Hide
          ASF subversion and git services added a comment -

          Commit 1659872 from David Smiley in branch 'dev/trunk'
          [ https://svn.apache.org/r1659872 ]

          SOLR-7005: don't add facet.heatmap.format=png to shard requests unless heatmaps are in use
          Not a bug; just a small cleanup.

          Show
          ASF subversion and git services added a comment - Commit 1659872 from David Smiley in branch 'dev/trunk' [ https://svn.apache.org/r1659872 ] SOLR-7005 : don't add facet.heatmap.format=png to shard requests unless heatmaps are in use Not a bug; just a small cleanup.
          Hide
          ASF subversion and git services added a comment -

          Commit 1659873 from David Smiley in branch 'dev/branches/branch_5x'
          [ https://svn.apache.org/r1659873 ]

          SOLR-7005: don't add facet.heatmap.format=png to shard requests unless heatmaps are in use
          Not a bug; just a small cleanup.

          Show
          ASF subversion and git services added a comment - Commit 1659873 from David Smiley in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1659873 ] SOLR-7005 : don't add facet.heatmap.format=png to shard requests unless heatmaps are in use Not a bug; just a small cleanup.
          Hide
          David Smiley added a comment -

          Closing. The optimization concerning distributed facet.field & facet.pivot refinement requests is now tracked as SOLR-7116.

          Show
          David Smiley added a comment - Closing. The optimization concerning distributed facet.field & facet.pivot refinement requests is now tracked as SOLR-7116 .
          Hide
          Timothy Potter added a comment -

          Bulk close after 5.1 release

          Show
          Timothy Potter added a comment - Bulk close after 5.1 release
          Hide
          David Smiley added a comment -

          Note: this code was donated to the Apache Software Foundation by the Harvard Center for Geographic Analysis as part of the Harvard Hypermap (HHypermap) and WorldMap projects.

          Show
          David Smiley added a comment - Note: this code was donated to the Apache Software Foundation by the Harvard Center for Geographic Analysis as part of the Harvard Hypermap (HHypermap) and WorldMap projects.

            People

            • Assignee:
              David Smiley
              Reporter:
              David Smiley
            • Votes:
              2 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development