Much of the API is consciously idempotent (e.g. reproject called on a 4326 RasterSource with the target projection 4326 will short circuit and not do any work). The naming conventions we've landed on don't really highlight this or disambiguate the non-idempotent (in the case of reproject, required by implementation) portions of the API and those methods which can be relied as idempotent (in the case of reproject, provided by the library).
Instead of this, we should consider an API that looks like this:
val rs: RasterSource = ???
rs.projected(4326, ...)
projected asks if an RS is already projected appropriately; if so, we're done; if not, call reproject (which in this case users will be expected to implement)
Much of the API is consciously idempotent (e.g.
reprojectcalled on a 4326RasterSourcewith the target projection 4326 will short circuit and not do any work). The naming conventions we've landed on don't really highlight this or disambiguate the non-idempotent (in the case ofreproject, required by implementation) portions of the API and those methods which can be relied as idempotent (in the case ofreproject, provided by the library).Instead of this, we should consider an API that looks like this:
projectedasks if an RS is already projected appropriately; if so, we're done; if not, callreproject(which in this case users will be expected to implement)connects #209