nickeubank / mtv_viacom_capstone

1 stars 0 forks source link

Jgy3 #67

Closed jgy4 closed 2 years ago

jgy4 commented 2 years ago

Hi all,

I updated the crs functions per Nick's note:

I also added Latitude/Longitude to 30_campuses_w_dist_to_nearest_pp.geojson for centroid calculations later.

This includes all of the updated code files, and updated output files.

nickeubank commented 2 years ago

Great! One issue in first file, otherwise great.

One note: in general, name your branches after what you're doing in the branch (here: "moving saved files to epsg 4326" or moving_saved_geojsons_to_epsg4326.). Your name is always attached to your commits, so using your name isn't adding info.

jgy4 commented 2 years ago

@nickeubank I updated the first file to maintain the projection before calculating the centroid. Unfortunately when reading the campus polygons in on 10_code/20_merge_data/20_calc_dist_to_nearest_pp_elecday.py I still found myself needing to use the override. For some reason, the geometries are holding onto their wkt form, even after being re-projected in 10_code/10_prepare_data/10_import_HIFLD_College_Polygons.py to EPSG 4326. Are we okay with this? Also might be due to a mistake on my end!

Also, thank you for the note about naming branches, I'll remember that moving forward!

nickeubank commented 2 years ago

Ah, got it!

OK, so what's happening is that we're now saving as EPSG 4326, which is being saved and preserved when we re-load the data. So in 10_code/20_merge_data/20_calc_dist_to_nearest_pp_elecday.py line 27, we now want to use to_crs() to re-project the data from epsg 4326 to our projected data.

Now we're in the world where override is doing the protective job it should be doing -- the data has a CRS and it's now the correct one, and so we don't want to override the one it has; we want to re-project/convert from its current to another.

See this section and the next: https://www.practicaldatascience.org/html/gis_crs_geopandas.html#Setting-a-CRS-(when-Missing)

jgy4 commented 2 years ago

Not sure I was clear earlier - I found the error! Line 101 in 10_code/10_prepare_data/10_import_HIFLD_College_Polygons.py geo_df = geo_df.set_geometry("geometry") was reverting the crs from EPSG back to WKT without my knowledge - so it appeared that the EPSG 4326 wasn't being stored correctly. Updating now and will merge afterward!

nickeubank commented 2 years ago

Oh! Got it, good catch. Yes, CRS conversions only act on the "active geometry" column, so when the geometry is changed, re-projections won't impact the no-longer-active-geometry column.