Rework ElevationModel and Z interpolation into interface

[bjornharrtell]

ref #655.

Summary of what this PR does:

• Extracts current implementation of Z ordinate interpolation into classes at namespace NetTopologySuite.Algorithm.Elevation
• Specifies an interface IElevationModel
• Implements a DefaultElevationModel with same as current behavior
• Implements a NoOpElevationModel that simply sets Z to be "interpolated" to a supplied constant value
• Introduces ElevationModel at NtsGeometryServices level defaulting to DefaultElevationModel

[FObermaier]

Thanks @bjornharrtell, I left some issues and suggestions in the code.

Beyond that I want to point out that maybe NtsGeometryServices should rather have an ElevationModel[Factory|Repository] that would return an ElevationModel for a given extent or geometry.

For that to be useful IElevationModel would have to have an Extent property (maybe SRID and priority, too). Users of the library could add their own IElevationModel implementations.

But this could also be achieved with different NtsGeometryServices instances.

[bjornharrtell]

Thanks @bjornharrtell, I left some issues and suggestions in the code.

Beyond that I want to point out that maybe NtsGeometryServices should rather have an ElevationModel[Factory|Repository] that would return an ElevationModel for a given extent or geometry.

For that to be useful IElevationModel would have to have an Extent property (maybe SRID and priority, too). Users of the library could add their own IElevationModel implementations.

But this could also be achieved with different NtsGeometryServices instances.

I agree an ElevationModelFactory would make sense. It is kind of emulated by the Create method on the interface itself right now which seem awkward. I will see what I can do after some more thinking.

[airbreather]

As is often the case in my reviews, I'm primarily focusing on the public API, since that's where I think I can add the most value on this one.

In general, I think the existing ElevationModel class gets away with some suboptimal API decisions, both because it's a class and because it's an internal implementation detail of one specific API. If it's going to stand on its own — from both the perspective of a) "let someone else implement this abstraction using FABDEM or something" and the perspective of b) "use an elevation model in contexts where it hasn't been used before — then I think the design of this API should come first without (much) consideration for what's already in OverlayNG.

My suggestion, based on (somewhat) ignoring existing callers and approaching this from a clean slate: could we build everything else on top of an abstraction that looks like this, as opposed to the IElevationModel that's being proposed here?

public abstract class ElevationModel
{
    public abstract double GetZ(double x, double y);

    // f is between 0 (inclusive) and 1 (inclusive), and it
    // indicates how far we are along the line from (x0, y0, z0) to (x1, y1, z1)
    //
    // big distinction is that we ask for the line segment and a fraction, instead of
    // asking for a point that we *assume* is *somewhere* along that line segment
    public abstract double InterpolateZ(double x0, double y0, double z0, double x1, double y1, double z1, double f);

    public virtual void PopulateZ(Geometry geom)
    {
        // default implementation calls our GetZ method, one-by-one, for each coordinate
        // a specific implementation might be able to benefit TREMENDOUSLY from batching
    }
}

[FObermaier]

New functionality needs testing!