warn for indices that expect certain projections

[knaaptime]

DistanceDecayExposure for example, expects wgs84. We decided against implicit reprojection, but we could do a check and raise a warning if we cant determine the crs is wgs84

[renanxcortes]

Hm.. I'm not sure if I follow... this expectation is due to the usage of euclidean_distances in line

segregation/segregation/spatial/spatial_indexes.py

Line 1244 in 44a1059

dist = euclidean_distances(

?
BTW, I think that we can improve these distances with the proper projections and so on... working with geodesic distance or something like this!

[knaaptime]

the original CRS is albers equal area, and if you try to compute DDE, you get 0. If you reproject into wgs84, you get 0.23

we might just check whether the crs is epsg4236 and warn if not. But agree, a more flexible handling of distance calculation would be prefereable

[ljwolf]

a ‘metric’ argument might be useful... that’d let you specify the right metric, and use haversine if the coordinates are in lat/lng

[renanxcortes]

a ‘metric’ argument might be useful... that’d let you specify the right metric, and use haversine if the coordinates are in lat/lng

I was thinking about something like this. Would you have some example somewhere that I could draw inspiration from? :)

[ljwolf]

This would be a good ref.

https://github.com/scipy/scipy/blob/v1.3.0/scipy/spatial/distance.py#L1736

I'd do euclidean, unless someone sends a crs with a units field in degrees?

[renanxcortes]

This would be a good ref.

https://github.com/scipy/scipy/blob/v1.3.0/scipy/spatial/distance.py#L1736

I'd do euclidean, unless someone sends a crs with a units field in degrees?

Thanks! Ok, but what about the above aea example that the units is in m? Shouldn't the haversine be applied to that case?

[knaaptime]

na its good, the meters means its already projected into a plane

[renanxcortes]

So, just for registration, the first example using the old only euclidean based measures was returning zero because of the magnitudes of the number of the albers equal projection. These are the centroids number:

which leads to these numbers after:

c = np.exp(-dist)
Pij = np.multiply(c, t) / np.sum(np.multiply(c, t), axis=1)
DDxPy = (x / X * np.nansum(np.multiply(Pij, y / t), axis=1)).sum()

Since DistanceDecayExposure uses np.nansum the resulting value was zero. I think if we rerun with this new haversine metric, the resulting value will make more sense.

[renanxcortes]

Ok, after discussing here with @knaaptime , things got clearer for me. So, actually using the haversine distance with albers projection is not correct since this crs is already projected to a planar plane. So, what we could do in this case is: if any problem due to the magnitude of the number occurs and generates nan in that distance matrix, raise a ValueError to the user.

Besides that, assuming that we'd like to help our users to use these functions, we need to create a bunch of specific tests using the .crs attribute of the input data. The idea is: if we "suspect" that the user is working with spherical coordinates, raise a warning saying: "It seems like you're working with unprojected coordinate system. Therefore, we recommend to set metric = haversine." but in any case calculate the index, because these tests might not capture different funky ways that the .crs might be. Did I get it right, @knaaptime?

[renanxcortes]

So, this is partially solved due to #100. However, I still think that a set of tests/conditions for the input of the GeoPandas to let the user aware of it would be useful. However, now the user can choose between euclidean or haversine distances but it is up to him to know the nature of his GeoDataFrame.

[knaaptime]

with the new pyproj integrated into geopandas, it should be much easier to create checks for CRS versions. Re-upping this thread to remind myself to revisit and rewrite those checks

[knaaptime]

this is breaking, e.g. compute_segregation_profile because it tries to introspect the .crs attribute with dict notation, but the CRS object isnt a dict anymore

[knaaptime]

geopandas has better CRS handling now (warnings for mismatches and warning when using distance with geometric proj) so closing this here