Closed AmandaDoyle closed 3 years ago
SPTKL
commented
3 years ago @AmandaDoyle can you elaborate?
Did clipped spatial boundaries get loaded? -> which boundaries?
By default boundaries without _wi suffix are clipped. please provide a list of boundaries and indicate if you would like them to be clipped or water included
AmandaDoyle
commented
3 years ago @SPTKL Apologies for the vagueness. I see that we load clipped boundary files for PLUTO, which is intentional. Let's table this issue for now, because I don't want to load in unclipped boundary files and then it have it impact something else.
AmandaDoyle
commented
3 years ago Spent some more time with this.
On Mar 30 we started switching data loading from fastloading.py to import from data library. This is when we came up with the convention that _wiwould indicate that a spatial boundary included water. Before this convention it was a hodgepodge and often no suffix indicating that water was included and _wo indicating a dataset was without water.
Many of the dataset coming from fastloading included water, but were not suffixed.
We need to update the spatial boundaries from data library to include the version with water (_wi) where a version with water exists. This should be applicable for:
Fix this for 21v3
bmlott27
commented
3 years ago Hi @AmandaDoyle and @SPTKL , it sounds like this issue may be why the clipped version of Pluto in release 21v2 is not clipped?
SPTKL
commented
3 years ago this is resolved, we had the wrong projection for the shoreline file, so the shoreline clipping didn't happen https://github.com/NYCPlanning/db-zoningtaxlots/commit/01208e2dc04d2c1f22c00b4a4fe93a31a127bb05
Also addressing this issue by using water included census tract / blocks and cd boundaries https://github.com/NYCPlanning/db-pluto/pull/282
In latest 21v2 some records along creeks are missing spatial data. Did clipped spatial boundaries get loaded? If this is an easy fix let's tackle it, otherwise it can wait until 21v3.
MissingGeocodes.csv