New Feature: Non Geo Table Entities / Tables

[pepperlk]

Need to abstract out the Feature to not include a IGeometry for basic table ops.

[davetimmins]

Did you have a particular use case thats not supported at the moment? Tables should work, you can set the Feature to use an arbitrary geometry or the IGeometry type. It'd be similar to using a feature but not returning geometry from operations

[pepperlk]

I am currently building an ORM on top of your library and not specifying the Geometry type would be useful is all because yes they do work, but not quite like id like.. Also ill own this one and would like to share the ORM feature with it if I can as well, look for a PR in the next little bit. (Never ask for a feature if you cant help out right??)

[brudo]

I agree; it would be more intuitive and readable if one could say await portalGateway.Query(new Query(...)) for queries where there is no geometry, or where you don't care about the geometry. But I will make due with specifying an arbitrary geometry type, and putting in a comment to indicate there is no geometry.

[brudo]

Incidentally, you cannot use IGeometry as the type parameter; it must be a creatable type, or it fails at run time. I used Extent in my case, because at least Extent could not be an actual feature geometry, so it might cause a developer reading the code to pause and think about it. However, it still warrants a comment, and smells a bit funny.

A type that explicitly means "no geometry" and that implements IGeometry might be clearer than co-opting Extent or Point. Then to provide a friendly shorthand for the common case where geometry is not needed for the input or output, we could add something like public class Query: Query<UndefinedGeometry> {}.

[brudo]

In follow-up, I notice that the fork maintained by @dymaptic includes a NoGeometry implementation and some other features specific to tables (initially from commits by @hbindervitti)