Redesigning Metadata processing and creating of meta-geometries

[Sov-trotter]

The current metadata handling features have been really interesting and there has been interest to expand it's functionality #50 #49.
The above mentioned issues have been made keeping in mind the heterogeneous nature of geometry/properties data. The present methods don't support this fully.
If I am correct, the way of creating meta-geometries is putting geometries and properties together into a StructArray, which works well for single geometries/properties or homogeneous geometries. The problem arises when we need a heterogeneous geometry with heterogeneous type like #49.

Now this functionality has been tested and implemented here we wish to extend it to GeometryBasics so that other use cases too can benefit from this API.

[Sov-trotter]

So the above GeoJSONTables solution works well for a list of Features(meta-geometries). Currently, what all can we have?

• A Feature(meta-geometry struct that has properties and geometries together)
• A StructArray that holds the metageometry
  I am not sure if we want to implement geometry specific metageometry constructors(we might as well).

https://github.com/Sov-trotter/GeometryBasics.jl/blob/meta_exp/src/metatest.jl is a start.

[sjkelly]

I think this is quite needed for a lot of geometries and algorithmic shortcuts. Is the current proposal non-breaking?

[Sov-trotter]

It is breaking indeed. We are moving from something like PointMeta to Meta{Point}. This is to solve #49.

[ffreyer]

Closing this since we removed the meta interface