Regression in boundary versions

[leeberryman]

@DanRunfola & @rohith4444 I've noticed a few things as the project's priority moved towards moving all licenses towards a very documented and defensible license found in one of the accepted license's: https://github.com/wmgeolab/geoBoundaryBot/blob/main/dta/gbLicenses.csv. This was a very much needed effort and should continue to be, but there have possibly been unintended consequences from these efforts that I think should be addressed through the acceptance process going forward. There are several instances of a newly accepted layer for a country being a much poorer quality shape than the previous version. I don't have all the answers, but would like to be part of the solution so I'm bringing it up here to be considered for discussion. @alex-imb & I have been doing some analysis on the current state of this issue in the project and could create issues to be tackled but first thought there should be some consensus on how to proceed.

[alex-geospatial]

We've found looking at the number of coordinates/KM of perimeter helpful. AFG_ADM1 and NPL_ADM2 (0.15 and 0.21, respectively), both in gbOpen, stood out to us. It's not foolproof, but I think looking at boundaries that have ≤ 1 coordinate/KM of perimeter seems like a good place to start.

We also recognize and celebrate the improvements the team has made in recent months and want to contribute to that pattern of success.

On that note, we found a solution, at least for these two cases. Assigning features in the next layer (ADF_ADM2 and NPL_ADM3) to the correct code in these layers (AFG_ADM1 and NPL_ADM2) and then dissolving would improve the precision quite a lot. This would require a fair amount of manual work, but only once.