Add sparse stitch method to StitchCollectionMethods

[CloudNiner]

Overview

Adds sparseStitch methods to SpatialTileLayoutCollectionStitchMethods. The method uses a different algorithm, and therefore it felt more correct to name it differently from the original stitch(): Raster[V]. Also added a helper so that users who want to use the collection extent don't have to know how to get it, since this is the most likely default use case.

Opened PR to get tests to run, since there's a breaking change on the type bounds of V. Initial testing in a few key places didn't raise any issues but I want the whole test suite to run. Edit: Full test suite passed, but upon further inspection it looks like we might not test stitch anywhere else.

Checklist

• docs/CHANGELOG.rst updated, if necessary
• docs guides update, if necessary
• New user API has useful Scaladoc strings
• Unit tests added for bug-fix or new feature

Notes

I want to add a unit test or two because there's nothing at all for any of these stitch functions, but that looks like its a bit of an effort since there's no easy test data constructor for the type we need to test. So submitting this for review now and moving on to a different task. I can attempt to add a test or two once we've settled on approval for the API presented here.

Closes #2903

[pomadchin]

LGTM actually! Only tests are required.

Also an extra question, mb it makes sense to add this method into SpatialTileLayoutRDDStitchMethods as well?

[CloudNiner]

mb it makes sense to add this method into SpatialTileLayoutRDDStitchMethods

Hmm. I'm torn. I think to add that method in that class I'd have to duplicate most of the logic and then replace the self.stitch with self.collect.stitch. Given that, it seems easier, if you have a TileLayerRDD, to just do tileLayerRdd.collect.toSeq.sparseStitch(extent) which should be possible with the current changes in this PR as long as the stitch implicits are in scope. It doesn't hide the collect (which is dangerous) and is still quite clear.

Only tests are required

Done. Added a few simple ones to geotrellis.spark.stitch.CollectionStitchMethodsSpec. It's an artifact of the spark split, but its still weird that a bunch of tests for functionality defined in layer are tested in the spark package. It would be very verbose to test those layer features without some of the spark helpers to construct the collections.

[pomadchin]

@CloudNiner but we already have this duplication

It is our API problem - that for the current collections API we have to duplicate everything. If you'll look more close - Collection API completely duplicates the RDD API ¯_(ツ)_/¯

I dunno what is better at the moment - to keep consistency or to add ambiguity by adding such a divergence into the API.

[CloudNiner]

Ah, if we're going for 100% feature parity between RDD and Collections API, then I guess I have to add it. Bummer.

[pomadchin]

Yea, I don't disagree with your point about duplication ): but it looks like at least for now it is better to add to keep everything consistent

[CloudNiner]

@pomadchin updated to include duplicate methods for RDDs

[moradology]

Consider the use of ++ instead of :::, but otherwise LGTM

[pomadchin]

LGTM, though I already feel too pedantic :/

[pomadchin]

Merging after the travis green light!