feat: spatial preview

[chriswhong]

Spatial Datasets can be stored as CSVs and made operable with qri without much effort in the following ways:

• for datasets with point geometries, coordinates can be stored in two columns, e.g. 'lat', 'lon', or 'latitude', 'longitude'

• for datasets with linestring, polygon, or multi, the geometry can be stored in a geom or geometry column either as a Well-known Binary or GeoJson string.

For this feature, I propose we do some inference to guess whether a dataset meets the above criteria, and offer a "spatial preview" of the body.

Switching to spatial preview would show a web map with simple markers/features, generically styled, and with a popup to see the associated attributes.

We could begin with just lat/lon columns (point features only) to get a working map view in place, and expand from there if there is demand.

[rustprooflabs]

I would love to see this support, I would vote for CSV form with geometry in WKT as a first goal to support.

Reason 1) The spatial section in the docs say to use CSV with WKT.

Reason 2) It's trivial to dump geometry from PostGIS using ST_AsText(geom). I imagine a good number of users of this feature will be PostGIS users. Other formats are not much more difficult in many regards, but this is clean and simple.

Reason 3) It works with all main geometry types, point, line, polygon, multi-everything.

Bonus reason) Simple geometries (point in SRID 4326) users see a "pretty" long/lat pair that most understand in the data. I loaded a Colorado Peaks dataset that illustrates that.

I published a dataset with a few WKT polygons, it was trivial to add the actual simple SQL query I ran to generate this dataset. I love this because 100% of the process is documented as code.

The GitHub repo referenced in the previous dataset includes a GeoJSON export from QGIS. I loaded that file to this GeoJSON dataset. When loaded as a full geojson data file you completely lose the ability to see the non-spatial data.

I love the spatial viewer implementation in DBeaver. I've had very good user experience with that over the past year. The original feature was discussed here if it helps to see how they approached the feature

I assume the first iteration will support only one SRID? 4326 or 3857 would a good starting point, lower level implementation details might dictate that decision.

It might be good to avoid the default column name of "geometry" to avoid colliding with the geometry data type name. Might not matter in Qri internally, but I would always rename that column when I inevitably load it to PostGIS if it were named geometry.