Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CRS checking utility #246

Open
jGaboardi opened this issue Feb 13, 2020 · 8 comments
Open

CRS checking utility #246

jGaboardi opened this issue Feb 13, 2020 · 8 comments

Comments

@jGaboardi
Copy link
Member

Following along pysal/tobler#50 and pysal/segregation#96 that @knaaptime raised regarding a new pyproj release, we may want to consider an embedded utility function that that checks for differing CRS of datasets.

@jGaboardi
Copy link
Member Author

See also Joris' blog post.

@knaaptime
Copy link
Member

well we got automatic utm zone detection in pyproj >=2.6, so i'd say the way to handle this would be to pin against that version.

then, we can test whether one CRS is equivalent to another and reproject into an appropriate crs if necessary. We'd rely solely on pyproj for that and no need to add extra handlers

@knaaptime
Copy link
Member

looking a bit closer at what was added to pyproj, i need to revise this--all it does is check whether the crs is a utm projection.

so we still need something like

def guess_utm(gdf, reproject=True):

    # calculate the centroid of the union of all the geometries in the
    # GeoDataFrame
    avg_longitude = gdf["geometry"].unary_union.centroid.x

    # calculate the UTM zone from this avg longitude and define the UTM
    # CRS to project
    utm_zone = int(math.floor((avg_longitude + 180) / 6.0) + 1)
    utm_crs = "+proj=utm +zone={} +ellps=WGS84 +datum=WGS84 +units=m +no_defs".format(
        utm_zone
    )
	if reproject:
	    # project the GeoDataFrame to the UTM CRS
	    projected_gdf = gdf.to_crs(utm_crs)
	
	    return projected_gdf
	return utm_crs

thats a pretty small and simple function now, so we could just repeat it across the packages, but could also make sense in libpysal

@jGaboardi
Copy link
Member Author

And we could swap in native pysal geometries is that kind of check, correct?

@knaaptime
Copy link
Member

🤷‍♂ I'm not sure, actually. i dont think ive ever used native pysal geometries. like, ever 😬

@knaaptime
Copy link
Member

one small complication is that if we wanted this in libpysal, there's not really anywhere in the current namespace that's super appropriate

@jGaboardi
Copy link
Member Author

one small complication is that if we wanted this in libpysal, there's not really anywhere in the current namespace that's super appropriate

What about common.py?

@knaaptime
Copy link
Member

huh. i didnt realize that was exposed at the top level... thought it was jsut io, examples, cg and weights

yeah, common would be the place

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants