Endpoints

[kamicut]

Endpoints we need to cover:

• [x] PUT /features/:id Modify geojson feature by id (modify properties + geometry)
• [x] DELETE /features/:id Delete geojson feature by id
• [ ] POST /features Create new feature
• [x] GET /features Get all features (without bounding box)
• [x] POST /commit Commit changes (modify/delete properties + geometries)
• [x] GET /features/:z/:x/:y Get features intersecting bounding box
• [x] Get /:z/:x/:y.pbf Get protobuf

@drewbo @dereklieu do we need an endpoint to batch import features and assign ids (logic covered in bin/import.js)? Anything I missed?

[drewbo]

@kamicut what does /commit do? I think we're fine without batch import and assign since we'll do that manually for a while. Could put it on a hypothetical future roadmap

[kamicut]

@drewbo I was thinking on save in the frontend, instead of an api call per feature, it would be a batch commit. The format I was thinking of:

{
  "added": [{ "Feature": { "geometry": [] } }, { "Feature": { "geometry": [] } }],
  "modified": [{ "Feature": { "geometry": [], "properties": {"id": "id5"} } }],
  "deleted": ["id1", "id2", "id3"]
}

[drewbo]

@kamicut gotcha, I think the front-end won't necessarily distinguish between added and modified; should we think about mimicking the logic from draw (if no id match: add, if match: update)?

[kamicut]

@drewbo sure, I don't see a problem with that. I think we should have the same id construction in draw and in the database 1dd78efb bin/import.js#L16

[dereklieu]

Agree with what's been said. Apologies if this is now repetitive, but as for the commit endpoint, I'm also leaning towards a simpler format than the one outlined. Can't really see what having separate added and modified actions gets us when we aren't confined by a rigid order of database actions a la OSM.

{
  "id1": { "Feature": { "geometry": [] } },
  "id2": { "Feature": { "geometry": [] } },
  "id3": null
}

If an id doesn't match, create one, otherwise replace the existing one, and either use null or another value to signify deletion (maybe the geometry array is just []).

[kamicut]

I think null is fine, but having an empty geometry I feel is semantically different from delete.

[kamicut]

@drewbo I don't think we should have a POST /features.json. If we're creating ids on the client, then we can have a PUT features/:id that creates a feature at that id. What do you think?

[drewbo]

That's fine since we'll create ids for all features (using the same method) on the client side. The only discrepancy would be created if people add features outside of the provided front end