GeoRSS tile expiry: do not expand mask Envelope for multiple Polygon entries

[justb4]

When the GeoRSSTileRangeBuilder encounters multiple entries in a GeoRSS feed it will let the GeometryRasterMaskBuilder aggregate the entries' geometries by expanding an initial Envelope from the first entry. In some cases like when geometries in the GeoRSS entries are widely dispersed e.g. around the globe, this will truncate/seed much more tiles than neccessary. Most of these tiles may be blanc.

The current implementation is as follows: for each entry GeoRSSTileRangeBuilder will call GeometryRasterMaskBuilder.setMasksForGeometry(geometry). setMasksForGeometry() maintains a variable "Envelope aggregatedGeomBounds" which it will expand after initial creation by calling expandToInclude() on this Envelope.

This behaviour (tiles reseeded for the aggregate Envelope of all Polygons) can be observed when constructing a GeoRSS feed that provides multiple Polygon entries in a single feed response. When the same feed is provided by a single subsequent Polygon entry in each feed response, only the tile area of each Polygon Envelope is reseeded. This is IMO the expected/wanted behaviour in many if not all cases.

The solution is to only build masks for each geometry, at least with Polygons. Points may be a special case.

[groldan]

good point.
The whole thing about aggregating before building the raster masks is to preserve memory. Otherwise we'd end up with too many geometries and may not fit in the heap. WRT to using the actual shape instead of the bounds that's an excellent point and it would be great to do that. I'd need to revisit the code and see how hard that would be. Hope not much.

Cheers,
Gabriel

[justb4]

The code is very involved thus hard for me to say something intelligent, but will try anyway ;-). The basic idea IMHO is to assemble a set of "dirty" tiles that need reseeding affected by the geometries from the feed entries. I had tried setting maxmaskLevel to 18 but that value was not accepted as the canvas would become too big. Possibly that is a point I don't understand from the implementation: building a canvas for each zoomlevel where each pixel represents a tile and then setting pixels for the envelopes of the rss entry geoms ? I think I don't get the "Canvas" solution. I would guess that for each layer zoom level a sparse 2D matrix could be build up that holds the dirty tiles. Also very involved and in worst case the matrices would not be sparse.

Isn't the following an idea for processing georss entries (have done a simimlar implementation in the past but with less constraints on geometries and projections)

1. "flatten" all geometries into individual Envelopes (or polygons)
2. combine overlapping envelopes (or polygons) (optional)
3. provide the set of envelopes (polygons) to the seeding process
4. the seeding process goes through all zoomlevels
5. for each zoomlevel tiles are seeded "touched" by the envelopes by looping through the envelopes
6. for each zoomlevel keep track in 5. which tiles have already been seeded such that they are seeded only once since multiple geometries may affect the same tiles

A suggestion, this is. There are always worst case scenario's based on the contents of the feed geometries. On the other hand if one is to use GeoRSS-based seeding, one has to be aware of any performance impact based on the content of the feed.

[groldan]

I see what you mean. Problem is we don't know when we're talking about billions of tiles and hence keeping track of which tiles have been touched is just non practical.

The one thing I'd try is to, instead of holding a raster mask per zoom level, having another kind of DiscontinuousTileRange that holds a single JTS geometry.
This geometry would be the union result of all the geometries coming from the feed, simplified to the distance between two center points of contiguous tiles at the highest zoon level, and buffered by length of a tile. It will be potentially huge too, but most of the times it should be smaller than a bunch of raster masks. Although it would take a bit of experimentation to get the correct balance.
Then the tile range iterator would ignore any tile whose geographic extent does not intersect this aggregated and buffered geometry.