Open API: Document endpoints to get MVTs for capital data

[TangoYankee]

Description

Document endpoints that return MVTs for city council districts, community districts, and captial projects

Acceptance criteria

• [x] MVT endpoints are created under paths
  • They are placed alphabetically within the list of paths, as practicable
• [x] The endpoints have a get method
• [x] The endpoints respond with
  • 200, which returns an MVT
  • 400, which returns a bad request
  • 500, which returns an internal server error
• [x] /community-districts/{z}/{x}/{y}.pbf
  • summary: Mapbox Vector Tiles for community districts
  • operationId: findCommunityDistrictTiles
  • tags
    • MVT
    • Community Districts
• [x] /capital-projects/{z}/{x}/{y}.pbf
  • summary: Mapbox Vector Tiles for capital projects
  • operationId: findCapitalProjectTiles
  • tags
    • MVT
    • Capital Projects
• [x] /city-council-districts/{z}/{x}/{y}.pbf
  • summary: Mapbox Vector Tiles for city council districts
  • operationId: findCityCouncilDistrictTiles
  • tags
    • MVT
    • City Council Districts

Helpful code snippet

/tax-lots/labels/{z}/{x}/{y}.pbf

Related tickets

Blocked by #225

[TylerMatteo]

@TangoYankee in the interest of time, I'm supportive of going with the /labels and /fills approach for CDs and CCDs. I don't think we'll actually need a /label endpoint for capital projects to meet the requirements but I'm supportive of creating one if time allows. I still think combining fills and labels into the same tiles is worth revisiting but I know we're both feeling like we're a bit behind schedule and this is an easy lever to pull if it helps us get back on track.

[TangoYankee]

The bottleneck is capital project shapes. Because they're represented as multipoints or multipolygons, we need to support both geometry types. If we want to streamline for development speed, we'll also need to split the /capital-projects endpoint into /capital-projects/multipoints and /capital-projects/multipolygons (hopefully we come up with better names if we choose this route). But, do we want to split things like this in the long term?

Zooming out, I think we have project-level bottlenecks that are much more significant. I'm not sure we really get much of a time savings on the overall project. But, we end up with an endpoint pattern we don't really like that much. It might be worth spending a day or two trying to figure out the sql to do it the way we want.

Also, would splitting it like this make things easier or harder on the front end? I wouldn't want to save time on the backend only to spend it on the front end.

TL;DR: Let's invest a day or two in researching the SQL that would get us capital project tiles that match these endpoints. If we start to go over time, we split out the tiles into separate paths.

[TylerMatteo]

Documenting decisions from IRL discussion with @TangoYankee. Correct me any of this doesn't match with your understanding.

1. We will only have one tile endpoint for projects. The tiles return by that endpoint will only have one layer. The SQL code for the implementation will conditionally take whichever geom column has data for any given project (either the multipolygons or multipoints). Therefore, some of the features in the tile layer will be polygons and some will be points.
2. We will attempt an implementation for admin tiles (CDs, CCDs) that also has one endpoint for tiles. Our initial approach will combine the features for the fills as well as the labels in one layer in the tiles.