Closed nreese closed 7 years ago
Do the problematic tiles always cross the dateline or do you see it elsewhere as well? Precision is computed based on envelope size in degrees (see GeohashUtil.java#L23-L24) so I suspect an update will be needed to handle case when tile crosses the dateline.
I found one case that does not involve the dateline
I'm wondering if this one could be an artifact of which tiles are being re-requested (and when) by the client. Maybe tips in this post or similar will help.
@nreese Can you take a capture of the network traffic in the browser as you experience this issue? That capture should indicate if a new tile request for that location is really being requested by the browser and sent back at the wrong spatial resolution.
The tile returned for the request http://localhost:8080/geoserver/elastic/wms?SERVICE=WMS&REQUEST=GetMap&VERSION=1.1.1&LAYERS=elastic%3Aevent&STYLES=earthquake&FORMAT=image%2Fpng&TRANSPARENT=true&HEIGHT=256&WIDTH=256&VIEWPARAMS=a%3A%7B%22aggs%22%3A%20%7B%22geohash_grid%22%3A%20%7B%22field%22%3A%20%22location%22%7D%5C%2C%22aggs%22%3A%20%7B%22metric%22%3A%20%7B%22max%22%3A%20%7B%22field%22%3A%20%22magnitude%22%7D%7D%7D%7D%7D&SRS=EPSG%3A3857&BBOX=-7514065.628545966,-7.081154551613622e-10,-5009377.085697311,2504688.5428486555 looks a little weird. It looks like some pixels are bigger than others. But, when you blow the tile up, the blockiness may just be an artifact of the data - having a very dense set of data that looks blocky.
@nreese, @GISDev01 Thanks for looking at this. The issue at the dateline is clearly a plugin bug. I'll at least take a look at that as soon as I can. But please report back if you find more evidence the issue is broader.
Just merged #38 which should resolve this. Please reopen if you still observe the issue.
I am running ElasticSearch 5.1.2 with an index containing all earthquakes recorded by USGS since 2013.
When zooming, not all of the returned tiles contain the same resolution.