Buffered bounds could be invalid

[prashtx]

We've encountered an issue when rendering a very large tile. Nodetiles buffers the bounding box, and the resulting bounds are invalid.

It might be difficult for nodetiles-core to check the bounds, since it would need to understand the valid ranges for each projection. It's probably easier to expose the buffer factor (potentially even as a function of the bounds and not just a fixed value), so that the caller can avoid creating inducing invalid bounding boxes.

/cc @hampelm

[Mr0grog]

It might be difficult for nodetiles-core to check the bounds, since it would need to understand the valid ranges for each projection.

Yeah, I think that's definitely true. Although… I think I originally wrote it that way with the assumption that there are no invalid values, since everything should wrap (e.g. if you're rendering the top-left-most tile, you want the buffer to include stuff from the top-right-most; that would be expressed as negative offsets from the right).

Based on that, I think it should probably be up to the data source should be handling wrapping. Are you actually getting an error because of the bounds from some underlying system, e.g. PostGIS?

Definitely agree the buffer should be better exposed or at least manipulable. Just having a fixed ratio (25% of render area right now) is not really great. Maybe as an option in the call to render? A default value/function should probably be set-able for the Map object, too: maybe Map.boundsBuffer. I'm imagining it would be either a number (used as a ratio, like the current constant) or a function (which would receive the bounds to be rendered and return new bounds).

[Mr0grog]

Anyway, let me know if you are already working on a patch along these lines. Otherwise, happy to work on adding buffer customization as described above if it sounds good to you and fits your case.

[hampelm]

We are getting an error from Mongo's $intersects query. We don't have a fix committed (I don't think that @prashtx is working on one -- we have a workaround that involves not serving big maps right now).

If you have time to add buffer customization, that would be super helpful. Your proposal above (especially a customizable value/function) would solve the problem.

[Mr0grog]

Ok, I'll try to get started on it this afternoon if I can. If not, sometime this weekend.

As an interesting side note, the MongoDB 2.4.9 docs for $geoIntersects say:

Any geometry specified with GeoJSON to $geoIntersects queries, must fit within a single hemisphere. MongoDB interprets geometries larger than half of the sphere as queries for the smaller of the complementary geometries. (http://docs.mongodb.org/manual/reference/operator/query/geoIntersects/)

Which poses an interesting restriction. Assuming that's probably not what you're running afoul of, though.

[Mr0grog]

The fix for this (#76) is published in v0.0.4, now available on NPM.