Add support for null geometry

[mcwhittemore]

Currently cardboard doesn't view null geometry as valid even though it is valid in GeoJSON. At first I thought that this was OK but I've had a few ideas recently that have been hindered by not being able to have features with no geometry set. What is the reason cardboard doesn't support this?

[rclark]

I'm inclined to continue to reject null geometries. This may have started as a geobuf limitation, but I bet that's not the case any longer (though we still use an old geobuf and should fix that).

But aside from that... what's the point? We're not all that interested in providing an arbitrary key-value store here, but in providing a datastore for spatial information.

[mcwhittemore]

I've been thinking about creating a world editing game for a little bit. In this game, each user is able to extract resources from the world and deposit them somewhere else. I see these extractions as features with null geometry but a set of properties. Now, I could set the geometry to be a point at null island or something so I don't think this would be a must, but it would be nice.

Another use case where I might want null geometry is a survey tool where each point on the map represents a user who has taken the survey. Part of the survey might be asking them to let me use the location of their device to fill out an answer. Some users aren't going to want to fill that out. For the sake of argument, let's say I'm ok with users not wanting to tell me where they are, now I have a survey result with no lng,lat. What do I do? Again, I could put it on null island and flag it as 'location not provided', or I could just not fill out the geometry. By not filling out the geometry I wouldn't be filling up my bbox requests that cover null island with non-located data which might be something I care about...

It looks like PostGis doesn't support null features. That said. PostGis also has all of SQL support with it so this isn't as much of a problem for it.

We're not all that interested in providing an arbitrary key-value store here, but in providing a data store for spatial information.

Cardboard is a dataset for spatial information but does that mean it's not also a key-value store? I think making this too limited to spatial information impacts the desirability of using it for spatial information.

In the two cases above, if I decided that using null island wasn't valid, then I'd need to introduce another datastore into my application. I could look at using a custom dynamo table but now I have two tables where I'd only need one if cardboard supported null geometry.

[rclark]

My take is that cardboard, and more specifically DynamoDB, are not good hosts for relational data. This is basically what your use-case boils down to -- using cardboard to store multiple "types" of data that are related in some way determined by your application.

When you build a DynamoDB table you've generally got some specific goal in mind for how you index, what your queries will look like, etc. You tailor the table to meet specific demands. While we know cardboard isn't there yet, generally the goal is to provide a spatial index. To try and use it to also hold arbitrary information with no spatial component seems backwards to me -- your application would likely be better suited by using another backend for relational content.

All that said, I think you're looking for a way for cardboard to act as a standin for other spatially enabled, relational databases, e.g. postgis or arc sde or a file geodatabase. I see this as an enhancement that we could pursue -- but I'm not sure that the right way to support it is to allow null geometries and force relational content to get stuffed into geojson objects.

[mcwhittemore]

Closing this as a wont-do.