Missing polygons feature in map widget

[Osares10]

Currently the map widget only allows the use of markers. Expanding the functionality of the map widget, or creating a new one that could handle polygon coordinates in the Leaflet GeoJSON format would be a great addition, expanding the capabilities of grist.

"coordinates": [[
            [-109.05, 41.00],
            [-102.06, 40.99],
            [-102.03, 36.99],
            [-109.04, 36.99],
            [-109.05, 41.00]
        ]]

Supporting this kind of figures:

[rambip]

That would be indeed really cool ! We have multiple use-cases for it in our team. I think I will try to contribute to this widget in the near future.

[paulfitz]

@rambip it would be great if you could contribute. The map code is pretty short and self contained, just some html/js/css https://github.com/gristlabs/grist-widget/tree/master/map

[rambip]

@rambip it would be great if you could contribute. The map code is pretty short and self contained, just some html/js/css https://github.com/gristlabs/grist-widget/tree/master/map

I'm thinking of 2 ways to implement this behavior:

1. Use field Coordinates which contains a list of tuples or a list of lists. This means that Latitude and Longitude are not required anymore, and the validation is a bit more complex. The specification could be: "provide either (Latitude and Longitude), either Coordinates. There is no explicit type: Point of Polygon is chosen automatically. Problem: what if the user has a Latitude, a Longitude AND Coordinates ?
2. Re-use the fields Latitude and Longitude to allow lists of points. This is probably a bit less intuitive but the schema does not change. Better: we can keep extending the widget by adding a Column Type that can be Point, Polyon, or LineString (for paths). Problem: a bit cumbersome if the user scraped geojson data and does not know how to transform it.

In both case, the logic is different from the geojson specification. In case 1, because we have Latitude and Longitude that can only be scalars (which geojson does not have). In case 2, because we split the 2 coordinates into 2 lists. IMHO, 2. is better because we can follow the entire geojson specification, the only difference is that we splited coordinates into 2 lists (which make sense, it's pretty hard to reverse the order of the tuples if you're not careful)

What would be the right approach in your opinion ? Will there be documentation to update ?

[marcchautems]

Such a feature would indeed be very nice and useful! About the two options you are wondering about, I am wondering if we should not save the full "geometry" string of the geojson in the table. I think this is also the approach that is used in R and python to deal with simple feature/geopandas in tabular form. In essence your attributes/properties are saved in the table columns and the geometry in the geometry column. Metadata such as the reference coordinate system (crs) are generally saved in the table properties, but for this use case I think we could restrict the option to only accept WGS84 (EPSG:4326)