Remove HRU Overlap

[abriggs-usgs]

Now that we have decided to go with hill shading we have a problem. It seems that the polygons that form the HRUs overlap. Prior to hill shading this was not an issue because we set the opacity of the HRUs to 100%. However, to make the hill shade show, we need to reduce the opacity of the HRUs and allow the hill shade to filter through from underneath. But, because the of the HRU overlap the overlapping areas are twice as dark as the non overlapped areas creating what appears to be a border.

To eliminate the false borders created by the HRU overlap we can return the HRU opacity to 100% and put the hill shading on top. However, the results are less than ideal.

This is an issue that needs to be addressed in some fashion prior to MVP delivery as one of the stakeholder requests was to remove the HRU borders. Perhaps this issue can be addressed by altering the HRU tile set to prevent overlap. Otherwise, we will be forced to accept a map with reduced aesthetic appeal or will need to contact the stakeholders to see if the light lines produced by the HRU overlap is acceptable.

Completion Criteria

• Prevent or somehow hide the false borders caused by HRU polygon overlap

[wdwatkins]

I suspect we are seeing this issue: mapbox/tippecanoe#562

One cause was simplifying the source data before it reached tippecanoe. I am going to to try eliminating the precision flag here: https://github.com/usgs-makerspace/wbeep-processing/blob/master/jenkins/hru_R_Jenkinsfile#L38

Other possibilities include:

1. the st_make_valid step is causing this, also in the that Jenkins job ☝️
2. this is an inherent issue with the geodatabase as it was given to us — not sure what we can do if this is the case, we would need to snap nearby points together, which could be dicey. Perhaps coverting to topoJSON and back would help?

[wdwatkins]

A few subsets of the HRUs at various points in the processing:

The raw .gdb as given to us, plotted with no border:

The shapefile that gets turned into the geojson that tiles are created from:

You can faintly see that there is a slight gap in between the HRUs in both. I'm guessing the gap represents the actual river channels. The gap doesn't appear to be affected by the processing steps.

I haven't been able to load the geojson into R that we create the tiles from -- I think it is too big, since R has to load everything into memory first. The ogr2ogr step shouldn't be doing anything besides changing the format, so I don't think its likely that makes a difference. I have dropped the flag that was setting the decimal precision in ogr2ogr, but it didn't seem to make a difference in the final tiles.

[wdwatkins]

st_intersects indicates that the polygons for both do actually intersect though:

st_intersects(raw_sample$Shape[3:7],raw_sample$Shape[3:7])
Sparse geometry binary predicate list of length 5, where the predicate was `intersects'
 1: 1, 2
 2: 1, 2, 4
 3: 3, 4, 5
 4: 2, 3, 4, 5
 5: 3, 4, 5

The next step IMO is to experiment with changing options in Tippecanoe. I think we may need to explicitly set the zoom levels, so that the highest zoom level corresponds to the limit in the style sheet. This will ensure that the --simplify-only-low-zooms option is gives us an unsimplified tile where we need it.

Another alternative would be to try some kind of fancy preprocessing to get the polygon boundaries to try to snap together. Maybe some kind of topojson conversion or quantization would help? Could also make some parts worse though.

[mhines-usgs]

Linking this separate ticket where it was attempted to use another data source for this issue: #172

[abriggs-usgs]

Gonna call this complete. Marty added 100% opacity to the HRU polygons and while this does not fix the issue, it does conceal it.