Generic feature

[supermihi]

Fixes #56.

@matt-lethargic appears that you've been just a day faster than me for once again on this! :) However, my approach also adds the geometrie's type as a generic parameter, which IMHO makes sense: a library consumer expecting a specific type of properties most probably will also expect a specific type of geometry.

If one doesn't want to specify the geometry type, one can use Feature<IGeometryObject, TProps>. Or perhaps it makes sense to keep both one- and two-parameter generic classes?

[matt-lethargic]

Hey @supermihi sorry, was in the mood for coding the other night and did this. Have got the code for what I guess you are doing on my pc, but not committed, Will checkout your PR

[supermihi]

@matt-lethargic Any news on this topic?

[matt-lethargic]

@supermihi Sorry I've been pulled away from this for to long. There are conflicts in the PR, would you be able to fix them so that we can compare your changes V's the change I put in and can then have a discussion regarding your changes??

[supermihi]

Sure. Basically, I have added another doubly-generic feature class, that specifies both the geometry and the properties types. I think there's no problem in keeping them both. The biggest issue IMHO is that #80 becomes a real problem here (see the in-code comment on Feature<TGeometry, TProps>.Equals).

[matt-lethargic]

@supermihi I've had a look at this and am happy to merge it, thank you for providing tests.
With regards to #80 I completely understand where you coming from and perhaps we should be including a check on the id for the other feature classes. This could lead to a breaking change though, so I'm pondering this!