Repository navigation
Update the vendored version of geos #228
Description
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.
Activity
micahcochran commentedon Dec 9, 2015
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 commentedon Dec 9, 2015
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 commentedon Dec 9, 2015
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 notifications@github.com
wrote:
WeatherGod commentedon Dec 9, 2015
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 ben.v.root@gmail.com wrote:
jswhit commentedon Dec 12, 2015
_geoslib.pyx contains some loops, which may be slow when converted to python loops calling Shapely.
micahcochran commentedon Dec 31, 2015
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 commentedon Dec 31, 2015
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 commentedon Dec 31, 2015
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 notifications@github.com
wrote:
micahcochran commentedon Jan 4, 2016
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 commentedon Jan 2, 2022
The latest release 1.3.0 from beginning of this week addressed this problem. In summary:
GeosLibraryis added in theutilsfolder to make the GEOS build a bit easier.GeosLibrarydownloads the requested version of GEOS from its GitHub mirror (using entirely Python modules). The compilation itself is done throughsubprocesscalls which depend a bit on the platform. For Windows,nmakeis used. For the rest,cmakeis used. The class assumes that these utilities are available in the user computer.