Instantiating many proj objects much slower than 1.9.6

I have a tool in pyproj 1.9.6 that I use for doing a “reverse lookup” of projections. Given an x/y in unknown CRS and a known longitude/latitude, this finds the projections which place that x/y closest to the known longitude/latitude. This is helpful when trying to track down an unknown coordinate system.

This requires instantiating thousand of proj/Proj objects, but it only takes a few seconds in pyproj 1.9.6. Recently I wanted to upgrade to more recent versions of PROJ and GDAL, but this tool is now taking a few minutes, about 50 times longer in pyproj 2.x:

• This gist takes 2.32 seconds to run with pyproj 1.9.6.
• This nearly identical gist takes 168 seconds to run with pyproj 2.6.1

I know that a lot changed in the underlying PROJ C++ library between pyproj 1.9.6 and 2.x. But is there any way to restore the fast instantiation of the proj/Proj objects? The projections don’t have to be exact - just close enough to this reverse lookup tool. Also, I am willing to serialize/pickle the proj objects if that would help, though my understanding was that that didn’t work with Python C extensions.

[dmahr1]

@snowman2 I definitely thought about using area of interest to filter projections. And that’s a really cool new helper function for querying them! But there’s nothing stopping a novice GIS user from (wrongly) using a coordinate system for points outside of the area of interest, right? In that case I think it’s better to be thorough and just check everything. Each request to the cloud function only takes about 500 ms 😃

[snowman2]

But it looks like the global context is leaving open a persistent connection to the database via the PROJ C API?

That was one of the settings that needed to be tweaked to get this to work. Also, adding the settings to the context beforehand and not updating them each time shaved off time.