PLUTO geometry repair

GIS currently repairs geometries in PLUTO files using code that requires an ESRI license. We'd like to do that without that dependency and during the build so that GIS doesn't have to modify files DE generates.

success criteria

• geometries are repaired during the DE build instead of the GIS script

todos

• compare DE and GIS mappluto geometries to see which lots currently become more valid (edm-recipes vs Bytes, or dev repeat vs main ingest)
• compare geometry precision between DE DB tables and DE export files
• confirm whether GIS script makes lots like Roosevelt Island lot (1013730001) more valid
• ...

stages and validity of lots

It's useful to know when lot geometries are invalid in the current process (source data, build, GIS scripts, ...). shapefiles were loaded into our build DB using ogr2gr

This is using 25v3.1, DTM version 20250827

summary from relevant research issue (link)

GIS script MapPLUTO_BP.py

Some high level takeaways (caveat, this was written many months after the initial analysis. Other details can likely be gleaned from the comments above):

• Geometry "validity" differs depending on what governing body is making the determination. And not just between Esri and open source, but also between say PostGIS and the tools in QGIS. This also means that running make valid in PostGIS, will not fix geometry errors that are flagged by ArcGIS/QGIS
• MapPLUTO as we build it now, contains all valid geometries per PostGIS, but has invalid geometries per QGIS + ArcGIS
• Exporting to different formats seems to carry over different geometry "errors"
• There are some known tax lots that seem to pop up over and over again - Roosevelt Island is a notable one. Others are flagged in the issue comments
• We've asked DOF many times to run the tools to ensure validity on their end, to no avail.
• Conversationally, I've learned that there is no known specific process that fails if we don't run a geometry fixer tool on PLUTO before distributing it (unlike, say, DTM that has to be repaired before we run ZTL build, or the action fails), but it's more of a maybe not super clearly defined ideal we've set for ourselves in the past

I think next steps are determining what level or definition of validity are we holding ourselves to. We might need to define some custom "make valid" operations ourselves. We will also potentially want to rectify some things that aren't technically invalid per the OGC spec, but that will throw an error in ArcGIS, since many of our data consumers are ArcGIS users.