Update the vendored version of geos

[WeatherGod]

While users can build basemap against other versions of libgeos/libgeos_c, the default action is to use the vendored version, which is at version 3.3.3 and is 3 years old. Conda packages are being built against this version because it is what is vendored. We should determine what version to bump ourselves up to, or figure out a way to make the basemap package more flexible to which version of libgeos is available.

Unfortunately, I don't have much expertise in this matter.

[micahcochran]

Shapely would be a good way to support GEOS functionality. It is one of the recommended ways to use GEOS library in Python. It has regular releases. Shapely has more functionality that is available, if needed.

_geoslib (the internal basemap code that interfaces Python to lib GEOS) and Shapely function names are almost identical. Except _geoslib has a .fix() which looks like a workaround that Shapely does not have.

I think using Shapely could simplify the code slightly.
with _geoslib you have this: NPole = _geoslib.Point(self(0.,90.))
with shapely you do this: NPole = shapely.geometry.Point(0.,90.)

[jswhit]

I think the reason I did not originally use Shapely was that it was too slow when operating on numpy arrays. This may have changed in more recent releases though, so it is worth revisiting.

[WeatherGod]

Good to know that switching to shapely shouldn't be too painful. Before we
do that, though, we should probably greatly expand the test suite so that
we can catch any sort of regressions that such an invasive switch could
cause.

On Wed, Dec 9, 2015 at 3:07 PM, Micah Cochran [email protected]
wrote:

Shapely would be a good way to support GEOS functionality. It is one of
the recommended ways to use GEOS library in Python. It has regular
releases https://pypi.python.org/pypi/Shapely#changes. Shapely has more
functionality that is available, if needed.

_geoslib (the internal basemap code that interfaces Python to lib GEOS)
and Shapely function names are almost identical. Except _geoslib has a
.fix() which looks like a workaround that Shapely does not have.

I think using Shapely could simplify the code slightly.
with _geoslib you have this: NPole = _geoslib.Point(self(0.,90.))
with shapely you do this: NPole = shapely.geometry.Point(0.,90.)

—
Reply to this email directly or view it on GitHub
#228 (comment).

[WeatherGod]

I haven't seen huge speed issues with shapely and numpy (although, I don't
have specific benchmarks to check). I also usually use the full cythonized
version as well. I will say that one pain point I have seen is with pyproj.
Doing great circle distance calculations using pyproj is slower than coding
up the haversine formula myself in python and feeding that function numpy
arrays.

Note, that wasn't a criticism of you or pyproj, just pointing out that we
should probably gather some profiling data to figure out for sure where the
slow points are in basemap because they may be in places we don't expect.

On Wed, Dec 9, 2015 at 3:10 PM, Benjamin Root [email protected] wrote:

Good to know that switching to shapely shouldn't be too painful. Before we
do that, though, we should probably greatly expand the test suite so that
we can catch any sort of regressions that such an invasive switch could
cause.

On Wed, Dec 9, 2015 at 3:07 PM, Micah Cochran [email protected]
wrote:

Shapely would be a good way to support GEOS functionality. It is one of
the recommended ways to use GEOS library in Python. It has regular
releases https://pypi.python.org/pypi/Shapely#changes. Shapely has
more functionality that is available, if needed.

_geoslib (the internal basemap code that interfaces Python to lib GEOS)
and Shapely function names are almost identical. Except _geoslib has a
.fix() which looks like a workaround that Shapely does not have.

I think using Shapely could simplify the code slightly.
with _geoslib you have this: NPole = _geoslib.Point(self(0.,90.))
with shapely you do this: NPole = shapely.geometry.Point(0.,90.)

—
Reply to this email directly or view it on GitHub
#228 (comment)
.

[jswhit]

_geoslib.pyx contains some loops, which may be slow when converted to python loops calling Shapely.

[micahcochran]

I wrote a small shim to try to import shapely as "_geoslib". I did not get too far. Suffice to say, there is some work to figure out if shapely would be a replacement.

@WeatherGod are you wanting to upgrade the internal version of libgeos to 3.3.9 (released Sept 4, 2013) or 3.5.0 (released August 16, 2015)? 3.4 seems to be failing build tests.

[micahcochran]

How about a different idea. What about using python-wget as a means to download libgeos? Then, you'd need a small amount of code that would extract the archive (zipfile/tarfile)--setup.py possibly could call that. This could completely remove the libgeos code from the project's github.

[WeatherGod]

no to wget, as that breaks debian rules, and really isnt a safe idea. I
think 3.5.0 would be fine.

On Thu, Dec 31, 2015 at 1:10 PM, Micah Cochran [email protected]
wrote:

How about a different idea. What about using python-wget
https://pypi.python.org/pypi/wget/3.2 as a means to download libgeos?
Then, you'd need a small amount of code that would extract the archive
(zipfile/tarfile)--setup.py possibly could call that. This could completely
remove the libgeos code from the project's github.

—
Reply to this email directly or view it on GitHub
#228 (comment).

[micahcochran]

I think that the directory for GEOS should be simply named geos/ (or possibly libgeos/), not geos-3.5.0/.

Why? Some of the files will rarely change between versions. I assume that the difference between versions would be smaller. Git currently has to download about 1 GB for development.

Either a file can be added under the geos/ folder to say that this is VERSION-3.5.0 of libgeos or the supplied libgeos version number could be added to the main project's README.md.

Are there downsides that I'm not thinking about?

[molinav]

The latest release 1.3.0 from beginning of this week addressed this problem. In summary:

• The bundled source code of GEOS has been deleted from the repository. Having a copy of the repository implies that we need to take care of updating the version manually by pulling from the official GEOS repos or mirrors, and this is not desired.
• Instead, a helper class GeosLibrary is added in the utils folder to make the GEOS build a bit easier. GeosLibrary downloads the requested version of GEOS from its GitHub mirror (using entirely Python modules). The compilation itself is done through subprocess calls which depend a bit on the platform. For Windows, nmake is used. For the rest, cmake is used. The class assumes that these utilities are available in the user computer.
• If the user does not want to compile the library by themselves, we offer precompiled binary wheels in PyPI for Windows and GNU/Linux. The precompiled binary wheels for MacOS are still not implemented in the GitHub Actions due to lack of knowledge from my side.
• Current release 1.3.0 is bundled with libgeos 3.5.1, only with the stable C interface. The rationale behind is simply that this is the only version I could compile successfully in all the target platforms for which I tried to build the precompiled binary wheels. Most of the problems come when trying to compile with MSVC on Windows. GEOS 3.6.5 compiles successfully for all GNU/Linux combinations and for Windows with Python 3.5+.