Closed ejm714 closed 1 year ago
@ejm714 I'm not sure this is a CRS issue. I think that point in the SF bay actually has latitude 37.763987 and longitude -122.3753 (switched - I have to look up latitude v longitude literally every time). cyano predict-point -lat 37 -lon -122
runs fine
I think we want the current behavior, at least for this failure. What fails is this line using geopy.distance.distance.destination
:
https://github.com/drivendataorg/cyanobacteria-prediction/blob/13d8fb38f63992d286baea36846672d20feba599/cyano/data/satellite_data.py#L45
From the geopy code here, they normalize longitude but don't normalize latitude because the normalization is less straightforward:
if abs(latitude) > 90:
warnings.warn('Latitude normalization has been prohibited in the newer '
'versions of geopy, because the normalized value happened '
'to be on a different pole, which is probably not what was '
'meant. If you pass coordinates as positional args, '
'please make sure that the order is '
'(latitude, longitude) or (y, x) in Cartesian terms.',
UserWarning, stacklevel=3)
raise ValueError('Latitude must be in the [-90; 90] range.')
if abs(longitude) > 180:
# Longitude normalization is pretty straightforward and doesn't seem
# to be error-prone, so there's nothing to complain about.
longitude = _normalize_angle(longitude, 180.0)
Ah yep you're right
The latitude of San Francisco, CA, USA is 37.773972, and the longitude is -122.431297.
Regardless, still good to support additional CRS, thanks for taking this on
I tried passing in a point from google maps for the SF bay and got an error
Which reminded me that we only support one CRS and don't specify what that is.
Minimum:
Nice to have: