Iws basin viz huc4s #12
Conversation
Merge branch 'add_rivers' of github.com:lindsayplatt/svg-maps into iws_basin_viz_huc4s # Conflicts: # 1_fetch.R # 2_process.R # 3_build.R
…s_basin_viz_huc4s
…'t slow down group_by>summarize
| p1_huc4s_simp_sf, | ||
| p1_huc4s_sf %>% | ||
| st_intersection(p1_conus_sf) %>% | ||
| rmapshaper::ms_simplify(0.01) |
There was a problem hiding this comment.
I had to add a st_buffer(0) before st_intersection to bypass a self-intersection topology error
There was a problem hiding this comment.
Should I add that in here? I didn't have to do that :(
| tar_target( | ||
| # Returns a list so that each river can be a separate SVG path | ||
| p2_river_coords, | ||
| sf_to_coords_by_id(needs_a_solution, | ||
| sf_to_coords_by_id(p2_rivers_all_sf, |
There was a problem hiding this comment.
Having separate SVG paths for each comid is probably more resolution than is needed for most projects. It might reduce file sizes to combine all separate paths that are the same style. Instead of having streams grouped by comid they could be grouped by basin and streamorder, so we can select by basin and style by streamorder. If streams are not connected we can draw a jump in a line by adding zm between path d's .
There was a problem hiding this comment.
If we did want it by comid, the map will probably be much more local map
There was a problem hiding this comment.
If streams are not connected we can draw a jump in a line by adding zm between path d's .
I'd love to hear more about this. The main reason I did it this way was so they wouldn't be connected.
change class and ids for huc4s
2 participants
Shows basins by HUCs and then rivers. Specific to the IWS-basins viz, but we may end up merging some of the workflow over to the
mainbranch at some point. Still waiting for this to build locally before calling it complete, but thought I'd put this up now.