Remove rasterio dep on pyproj

[banesullivan]

Draft work to remove the rasterio source module's dependence on pyproj.

Considering how easy it is to install pyproj these days, I don't think this is totally necessary but it's probably best to have the rasterio source module use rasterio directly for everything rather than pulling an additional dependency.

There is still one remaining function getPixelSizeInMeters() that I wasn't immediately sure on how to reproduce with rasterio

[manthey]

We could make a dependency on geographiclib, which is an MIT-licensed pure python library. Then

geod = geographiclib.geodesic.Geodesic.WGS84
s1 = geod.Inverse((bounds['ul']['x'], bounds['ul']['y'], bounds['ur']['x'], bounds['ur']['y'])['s12']
...

Really, getBounds is doing the heavy lifting here.

[banesullivan]

I think geographiclib is C++ with Python wrappings? Either way, I think the goal with this PR should be to reduce dependencies for this operation

[manthey]

I think geographiclib is C++ with Python wrappings? Either way, I think the goal with this PR should be to reduce dependencies for this operation

The geographiclib python package seems to be pure python without any lib dependencies, but reducing dependencies is worthwhile in and of itself. We are using pyproj to compute the distance between the corner points and using that to compute the average dimension of a pixel. We could have a simple fall back where if pyproj isn't available, we calculate the great circle distance on a sphere and accept that it could have 0.5% error.

[banesullivan]

It's worth trying this to at least see how different the results can be for our testing data. @manthey, is that math something you are familiar with or should I do some research into how to do this?

[banesullivan]

@12rambau, do you have any thoughts on depending on pyproj with the rasterio source module?

[manthey]

It's worth trying this to at least see how different the results can be for our testing data. @manthey, is that math something you are familiar with or should I do some research into how to do this?

We put the Vincenty functions directly into geojs, though we probably should have just pulled in a package. They aren't hard, but fussy and not the sort of thing I think we should have since so many other packages implement that. The simple great circle distance on a sphere is just trig (see https://en.wikipedia.org/wiki/Great-circle_distance) to get an angle multiplied by the average radius of the Earth; if we are doing a fallback to avoid a package, that is probably all we want.

[banesullivan]

Sounds good and simple enough! Will add to my todo list to do the great circle estimation then see if it skews results too differently

[banesullivan]

That was easy! Tests pass for me locally and as far as I can tell (few surface level tests), there isn't any visible impact on tiles or thumbnails

[manthey]

The biggest difference I see is in sample file test/test_files/rgba_geotiff.tiff, which reports a pixel size of 8.181m rather than 8.170 m.

[12rambau]

oups I'm a bit late to the party. I'm usually depending on the CRS module of rasterio which is sufficient for my applications. It seems a bit more complex from your side but the solution you found is elegant enough.