Remove special handling of geographic (longlat) CRSes

[djhoese]

This includes fixing handling of lon/lat projections that didn't have a prime meridian at 0 (of the traditional prime meridian sense). This also means that we now properly treat lon/lat projections as not equal. As part of this, Pycoast had a special Proj class for backwards compatibility with pyproj that has been removed. Lastly, the one place that we need to know if something is lon/lat or in a metered projection was in the "from config" overlay logic where it got a default resolution based on the AreaDefinition's resolution. This has been updated to perform logic based on the units of the CRS, not just on it being geographic or not.

NOTE: This PR is based on #96 so there are a lot of commits. I can rebase this after that PR is merged.

CC @lobsiger

• Closes #xxxx
• Tests added
• Tests passed
• Passes git diff origin/main **/*py | flake8 --diff
• Fully documented

[coveralls]

Coverage: 95.535% (+0.04%) from 95.5% when pulling 8915260 on djhoese:bugfix-longlat-crs into 8d83d2e on pytroll:main.

[djhoese]

@mraspaud and @lobsiger, this PR is now ready for review. It fixes some issues I was running into. Now that #96 is merged, I rebased this so it is only 1 commit now.

[lobsiger]

@djhoese @mraspaud I installed with pip and tried this PR with the lonlat area (using pm: 180) as you proposed here #95 (comment) and I get the old problem of horizontal scratches that I already solved one year ago. Did I miss something?

[djhoese]

Yes and no. This PR fixes the issue that current pycoast would treat all lon/lat projections the same. So if you did something with +pm=180 you'd get completely incorrect or flipped coastlines because of the way the projection was being handled. This does not handle shapes/polygons that cross the anti-meridian. Until now I think we benefited from the shapefiles being split at the antimeridian, but now with these different projections you can end up with longitude 0 being the antimeridian for the image (+pm=180).

I was going to save fixing this for another PR.

[lobsiger]

No problem. All you have to do is take pm: 170 (as I explained for my OPC MSLP projections 2022) and shift the area extent by 10° in x direction. It must be noted that the same result can be achieved today (without PR) with projection eqc and area in meters.

The scratch problem you see above in my image is caused by the 0° meridian the antimeridian of 180° that is crossing Spain where the coastlines are part of the huge Eurasia polygon. If you move pm: (seems to be the same as lon_0) to 170°, then the (-10°) antimeridian does not cut the Eurasia shape. I still think we should let the solution for the scratch problem as is though it cannot handle all possible cases (with very big areas). This is similar with resampling that also fails with a couple of available projections.

[djhoese]

This is not about finding a workaround for a use case, but fixing the library not supporting something it should logically support. As for the solution, it becomes just another condition in the indexing function. I have a fix for it but it makes a few assumptions so I didn't make a PR yet.

As for resampling, what projections? In pyresample?

[lobsiger]

@djhoese I have never used 'lonlat' as a projection name before. So I even didn't realize there was a problem here.
The PR solves this resampling problem and does still allow for the needed coastline workaround pm: 170. LGTM.

RESAMPLING: In this thread I found that only the "nearest" resampler worked as expected for all my LEO images.
https://groups.google.com/g/pytroll/c/8Fpo9QszZyc

Except for Mollweide (moll) even the "nearest" resampler seems to fail for pseudoconic projections.
Below Aitoff (aitoff, also the pycoast grid fails) and Sinusoidal (sinu) as examples of failing projections.
All these use standard lon_0: 0 and lat_0: 0. I do not propose or even expect that all this must be fixed.

[mraspaud]

I'm not sure I agree here. From what I understand, this PR finds the resolution at the equator, while the previous version use the location of the area to find the correct local resolution. This is important for areas far from the equator, where the resolution computation would yield very different results.

[djhoese]

@mraspaud This PR is much more than the change in the resolution helper function. But as for the new resolution guessing logic (ex. _estimate_metered_resolution_from_degrees) it depends how you look at it. It uses the equatorial radius, but for a spheroid Earth this would also be the polar radius so the result of the calculation should be the arc length anywhere on the Earth. The guessing function is already taking the minimum between X and Y resolutions so the level of accuracy is pretty low already.

Additionally, this resolution guessing for is_latlong() projections in the old version didn't actually work from what I can tell. It built a Proj object and then transformed the degree extents to...degrees? Or maybe radians for older versions of pyproj? Regardless the resulting value was not useful for the if statements that follow which use meters.

So while this may not be the most accurate and I'm fine changing it if you have suggestions (use the polar radius? use the minimum of the arc length calculation with the polar and equatorial radius? other?), this only changes how long/lat projections are handled and it didn't work prior to this anyway. Existing metered projection handling should be the same.

[mraspaud]

This looks good to me.

Just one last question before we merge: do we have an image comparison test for a latlong area?

[djhoese]

Just one last question before we merge: do we have an image comparison test for a latlong area?

No. I thought about that, but realized that I didn't technically need to for this particular set of changes as I'm just making sure that the different projection parameters have an effect on the final result. If you want one I can make one. Just more stuff to include the sdist/wheel and the repository.

[mraspaud]

Just one last question before we merge: do we have an image comparison test for a latlong area?

No. I thought about that, but realized that I didn't technically need to for this particular set of changes as I'm just making sure that the different projection parameters have an effect on the final result. If you want one I can make one. Just more stuff to include the sdist/wheel and the repository.

Yes, I think one test image would be good, close to one of the poles would be better.

[djhoese]

@mraspaud Added. Ready for re-review and merge.

[mraspaud]

LGTM