mapbox / mapbox/mapbox-gl-draw

Supporting Non GeoJSON Shapes via Custom Shapes

Open
#761 3 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

feature
Dominant language
JavaScript
Stars
1.1k
Forks
612
Avg merge
8d 9h
Merged PRs (30d)
5

Description

Currently Draw is tightly coupled with the GeoJSON spec. I've long defended this decision because I think it helps reduce bugs by limiting the surface area Draw needs to manage to the GeoJSON spec. That said, a few months back @flippmoke, @sgillies and myself had a conversation about the [vector tile spec](https://github.com/mapbox/vector-tile-spec) that made me start to question if the job of Draw is to create good GeoJSON or if its to create data to be rendered to the map which could be any content type than can be turned in the vector tiles.

Anyway, while time has not given me clarity on how Draw might change to create VT rather than GeoJSON, considering the consequences of such a shift has convinced me that user defined Custom Shapes should be a thing in Draw just like Custom Modes.

Some custom shapes that I have in mind are:

- Square
- Triangle
- Hexagon
- Circle

You know, simple things people have asked for for a long time but I've said no to because they aren't in the GeoJSON spec.

## Why custom

The main problem I've long had with the out of spec shape suggestions is that they all depend on adding a magic property to a Feature. While this is a great idea (really) the fact is that much of the GeoJSON users drop into Draw wasn't created by them and thus might use said magic property for different reasons.

That said, as a developer, you should have the power to create great software despite the above problem and, the best way I see to do that well, is custom shapes.

## How would these work

Like we did with modes when creating the custom modes, the Draw API would need to expose a way to change the list of shapes by passing your own JS objects into Draw. For modes we let you drop the core modes if you wanted to, for shapes we'd continue to require Point, LineString, Polygon and their Multi* counterparts to stay.

Part of the Custom Shape interface would be a function that takes a GeoJSON Feature and returns `true` or `false` to indicate if this GeoJSON matches the Custom Shapes convention like the code below.

```js
var square = {};

customShape.featureIsShape = function(feature) {
// This would be a pretty poor check
return feature.properties.type === 'square';
}
```

## Would `draw_polygon` make my shape?

Nope. Custom Shape creators would likely want to create a Custom Mode to draw their shapes.

## Next Steps

Does this sound like a good idea to other users out in the wild? If not, please explain what your concerns are below. If so, do you have any time to put into helping make this happen either via PRs or brainstorming?

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the proposed Custom Shape interface and the existing Custom Modes approach described in the issue. The issue does not name files, tests, or an implementation entry point, and completion would require agreeing on the API and shape behavior before implementation.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript
Domain
frontend
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.