NoisyFlowers
commented
5 years ago This turns out not to have been a problem with gdal at all.
In July 2018, we switched the srid of all our tables to 4326. At this time azlibConfigGDB would load a config gdb into the database and then tweak it with sql. The change to 4326 was made in this sql.
In October of 2018, we completely changed how gdbs are imported. Instead of loading a config gdb then tweaking it in azlibConfigGDB, we decided to do all this once then backup that db. azlibConfigGDB would then use that backup to configure the database. When this change was made, 26912 crept back in as the srid for all the tables.
I've changed the srid's back to 4326 and the layers in question appear to display properly when imported with the new codebase.
On dev, there is a db called tmplibrary that is fully populated and includes these changes. It looks good to me but should probably be further compared to the existing azlibrary on that machine.
The following map is plotting in the wrong place entirely (Western New Mexico). http://repository.azgs.az.gov/uri_gin/azgs/dlio/1382. This map is collection 321 on production.
The map is in projection NAD 83 / UTM 11N, SRID = 26911. QGIS, ogr, and Arc all agree. However, the azlibrary database is reading it as NAD 83 / UTM 12N, SRID = 26912.
I found an old issue on https://trac.osgeo.org/gdal/ticket/2123 that suggests this problem was patched, but I guess it doesn't work in all cases or perhaps we need to update our GDAL versions?
We may need to do our own manual check moving forward during the add process that verifies the SRID input into postgis actually matches. We can put this off until after #1 is completed, but I am flagging this as high priority for @NoisyFlowers.