1

I am trying to build a database for NYC in which, for specific boroughs of the city, I track changes per tax lot unit in terms of land use and other attributes, both qualitative and quantitative. For example, I am trying to track the changes in land use or Floor Area Ratio per tax lot through time.

For this, NYC offers extensive data in their database mapPLUTO, which can be found here, both for 2018 and historic data that traces back to 2002.

So my initial approach is to arrange the attribute tables of each year and compare the fields I am interested in, from year to year, creating something like a series of columns that express whether there has been any changes between year a and a-1.

This would be an easy and straightforward process if tax lots where always the same, but between 2002 and 2018 construction and development has taken place, increasing the number of lots by subdividing them. Below, two images compare the tax lots of 2002 and 2018 over an area that was developed:

tax lot in 2002

Tax lots in 2018

This situation gets even worse regarding the coding of the data: in 2002, the lot was identifiable via 2 attributes, being block (169 in this case) and lot (the lot number within the block, being = 1). However, in 2018, all the new tax lots get a new lot number, and one of the new entities has the value 1, meaning that the datasets from 2002 and 2018 have both an entity identified as 169-1, but this entity is not the same.

My question is, then, whether there might be a methodological solution for how to be able to track changes between datasets that have different entities in place, which makes it hard to compare entity-to-entity.

I have a possible path to overcome this problem, which you may comment on, or add an alternative. My first option is to perform the analysis per block. That way, the first step of my analysis would be to ask whether the block has the same amount of tax lots or not. Then, for each block, data is retrieved from its tax-lots and aggregated at the block level, which becomes the research unit.

Another way of fixing this issue might be to do some kind of spatial join in which the latest version of the database "inherits" the info of previous years. however, the two datasets do not fully overlap even though they have the same projection, leading to some lots not to overlap with their past selves (see image below) representing 2002 and 2018, with the latter in yellow lines).

enter image description here

This study is being carried out in R.

  • Update: when the boundaries of the tax lot themselves do not matter, and their attributes can be converted to relative variables (e.g. population density, percentages, etc), the people I am working with usually rasterizes these layers so that values are contained in raster cells and a continuum is created. This might be useful for somebody. To me, however, it is not useful in this case. – Pablo Herreros Cantis Nov 15 '18 at 21:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.