MVP Endpoints #21
Replies: 2 comments 9 replies
-
General rules
Breaking the general rules
Summary of endpoints
|
Beta Was this translation helpful? Give feedback.
-
|
I was thinking we would just grab the color out of the list of zd classes on the frontend but if you think it's worth having another endpoint, fine by me. What's are the use cases for |
Beta Was this translation helpful? Give feedback.
-
Yeah! Let's experiment and review the experience afterwards
The abstract answer is: to give users access to the data for a use we may not imagine but they may still desire. You may retort well, why provide such a route for zoning districts but not tax lots?. I do think we should also provide an equivalent tax-lot route. But, there are so many tax lots that we would need pagination to avoid freezing the applications. Zoning districts should at least be small enough that an unpaginated request would only be slow, instead of breaking. The practical is answer is: we don't need them for the pilot and so we can exclude them I crossed them off the list |
Beta Was this translation helpful? Give feedback.
-
|
Gotcha, yeah let's keep this list specifically the ones we need for the demo. I was going to bring up the can of worms that is pagination but luckily we don't have to cross that particular bridge yet. |
Beta Was this translation helpful? Give feedback.
-
Hmm, should we also shelve |
Beta Was this translation helpful? Give feedback.
-
|
@TangoYankee Other thoughts:
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
@TylerMatteo I made a consolidated list. Any more changes before we start making tickets? Also, the following comment is how I see the work being divided. I figured that most of the work is in making schemas to reference. So, the routes should be split based on what schema they return. |
Beta Was this translation helpful? Give feedback.
-
Ticket ARoute that returns zoning district (blocks tickets B and C because it creates the zd schema)
Ticket B (Blocked by ticket A)These routes return land use, borough, zoning district and/or tax lot schemas
Ticket C (Blocked by ticket A)These routes return zoning district or zoning district class schemas
|
Beta Was this translation helpful? Give feedback.
-
|
The implementation tickets will follow the same breakdown as these documentation tickets, with each implementation ticket blocked by its corresponding documentation ticket |
Beta Was this translation helpful? Give feedback.
-
Let's sketch out which endpoints we need in addition to the
/boroughsone already speced out in #9 !/tax-lots/<bbl>or something more verbose that conveys the hierarchy of borough-block-lot, such as/boroughs/<borough_id>/blocks/<block>/lots/<lot>. @TangoYankee I think we settled on the simpler BBL approach last time we discussed this but open to discussion. We know that the frontend end will need to pan the map the a tax lot when the user looks up a borough, block, and lot. Depending on exactly how that interaction with Deck works, this endpoint will probably need to return geojson. In that case, we could append/geojsonon the end, implying that an endpoint without it would include only the properties about the lot and not its geometry./tax-lots/<bbl>/zoning-district/zoning-district-classes/zoning-district-classes. We probably want this to return all of them in one go so that we can use that data to do things like render out the toggles for hiding/showing districts on the map. My initial thought was that this would be an object "indexed" by the class ideas but on second thought I think it probably makes more sense to just return an array of zoning district class objects and convert it to the nested object structure on the front end if needed./land-uses- Same deal as zoning district classes, but for land uses/zoning-district-classes/<id>This endpoint supports the functionality of what happens when a user clicks on an individual zoning district on the map. We'll have the zoning district's class id via Deck when the user clicks on a polygon but stuff like the description is associated with that class. If we decide to just get a reference to the class from the list of classes on the front end, we may not need thisVector tile endpoints
/tax-lots/<z>/<x>/<y>.pbf/zoning-districts/<z>/<x>/<y>.pbfThese endpoints will redirect traffic to S3 storage but I'm thinking maybe we don't include them in the
openapi.yamlfor now? There are ways to represent protocol buffer-encoded responses in OAS but it might something we should punt on for now.Beta Was this translation helpful? Give feedback.
All reactions