adds generic FeatureCollection

[wagich]

This PR adds a generic FeatureCollection<TProps> (and creates an interface for Feature to implement because TGeometry needs to be covariant). This enables the property objects in each feature to be directly serialized using JSON.NET instead of manually using a dictionary. See #104 for use-case.

[supermihi]

Looks good to me. Actuallty, it would be nice to have a non-generic IFeature interface above the generice version. Currently, the situation is somewhat awkward because a Feature<T> is not a Feature (in the OOP sense), which it should semantically be.

[aplitomart]

It would be cool to have generic version of FeatureCollection also because sometimes I have to mark properties inside Properties with JsonPropertyAttribute, and constructor of a non-generic Feature converts properties object into a dictionary with property names as keys ignoring names in JsonPropertyAttribute.

[YaroslavKormushyn]

@matt-lethargic would this be possible to include in the next RC if I were to adjust it a bit to the latest codebase? I'm using strongly-typed properties in my features, which is a real pain to configure with the serializer/deserializer mechanism right now.

[matt-lethargic]

Hey @YaroslavKormushyn forgive my memory, what would be the goal be for this?
I've no idea why this got closed TBH

[YaroslavKormushyn]

Hey @YaroslavKormushyn forgive my memory, what would be the goal be for this?
I've no idea why this got closed TBH

This is a change to the existing rigid typing of FeatureCollection and Feature to make them extendable, e.g. define strongly-typed properties for features and allow to follow the L in SOLID.

Right now (for me at least) to have a strongly-typed properties object in the features and make it work with the json serializer means recreating the collection and feature classes with the necessary types and using those. This PR makes this easier by having generic interfaces. This still should have a default implementation, so that existing code works without change.

[YaroslavKormushyn]

On that note: is there a way to define a FeatureCollection with features that have strongly-typed properties (and still have the flexibility of omitting the geometry)? Right now we have a FeatureCollection where each Feature has an IDictionary<string, object> properties type. If we want to have that dictionary as a custom type with its own model validation and rich functionality - we should either inherit from existing FeatureCollection or copy-paste the FeatureCollection implementation, but substitute the List<Feature> for List<Feature<IGeometryObject, MyCustomPropertiesType>>.

I may be missing something here because I didn't read through all the available types and how they were written.

[wagich]

Nice to see this get some traction 👍 TBH I've since switched to different library, but would be happy to help.

@YaroslavKormushyn: regarding your last comment, I'm not sure I follow…
The generic feature collection from the PR already doesn't really care about the geometry, the list is typed as IFeature<out TGeometry, TProps> where TGeometry is covariant so you can add a feature with any geometry.

[YaroslavKormushyn]

@wagich yeah, you followed it perfectly, the PR covers everything we need :)

[YaroslavKormushyn]

I will be creating a PR with these changes to the current codebase later today. I'll mention the original authors so that we can trace these changes correctly and add a mention to this PR.