-
Couldn't load subscription status.
- Fork 0
Update interim version of watersurfaces_refpoints #80
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
base: interim_versions
Are you sure you want to change the base?
Conversation
| ``` | ||
|
|
||
| However, it is possible and expected that new `polygon_id`s may pop up in new versions of watersurfaces_hab that at least overlap previous polygons, if not be equal to them. | ||
| First of all, this happens because `polygon_id` values may be different in interim versions of watersurfaces_hab compared to regular versions. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It appears that the polygon_id_habitatmap in the interim version is based on a different coding system and can not be compared with polygon_id_habitatmap in the previous versions. Therefore, in the interim version, all polygons for which the id is based on the habitatmap (because no overlap with a watersurface object) appear to be new. In fact, most of them are identical to polygons in the previuos versions.
It is good that the new wsh polygons adopt old reference points that are within the polygon. However, you create new records (with new polygon_id's) that actually correspond to an already existing polygon in watersurfaces_hab.
If you want to use the interim version of watersurfaces_hab, I suggest follwing steps:
- check for new polygon_id's
- if the new polygon_id is based on polygon_id_habitatmap and the new polygon overlaps with 1 polygon in an older version of watersurface_hab: spatially compare polygons
- if the overlapping polygons are equal: use the polygon_id of the previous version
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right that this will create multiple entries referring to the same polygon, using alternative polygon_id values.
The interim versions of habitatmap_stdized and derived data sources only have this alternative polygon_id flavour.
Hence the reason for accumulating both polygon_id flavours in watersurfaces_refpoints in the case of identical (or overlapping) polygons, is that the interim version of watersurfaces_hab only has the alternative polygon_ids, i.e. for the polygons that stem from the interim version of habitatmap_stdized. In order to easily join watersurfaces_hab with watersurfaces_refpoints (using the same interim version), we need the alternative polygon_id.
This is also a reason to keep the interim versions of watersurfaces_refpoints separate from the regular releases, since the latter never need the alternative polygon_id flavour.
Further, the regular version of watersurfaces_refpoints already has this feature of accumulating links between unique polygon_ids and (potentially duplicated) reference points, across watersurfaces_hab versions:
- new
polygon_idvalues of polygons that overlap an existing reference point, lead to new rows that recycle the existing reference point. It is not verified whether the corresponding polygon geometrically matches an existing one; new rows are added so that joins withwatersurface_habwill provide correct reference points. - no discarding happens of
polygon_ids that do not exist in the corresponding version ofwatersurfaces_hab, since no conflicts are expected (the same id being used for different things). Hence we already had backward compatibility with olderwatersurfaces_habversions. In the case of the interim version, the backward compatibility holds for the interim and the regular versions together aspolygon_ids are accumulated.
So I rather suggest to keep this philosophy of accumulating new IDs, both in the regular and the interim variant. What do you think @ToonHub ?
| filter(nr_points > 1) %>% | ||
| print(n = Inf) | ||
| ``` | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To check if the overlapping polygons have the same geometry, we can calculate the distance between (1) the result of st_point_on_surfaces() for the new polygon and (2) the coordiantes of the refpoint of the old polygon.
For most overlapping polygons we get small distances, which are caused by rounding the coordinates in v6 of watersurfaces_refpoints.
| ```{r paged.print = FALSE} | |
| check_overlap <- wsh_new_point_exists %>% | |
| filter(!is.na(polygon_id_previous)) %>% | |
| mutate( | |
| nr_points = n(), | |
| .by = polygon_id | |
| ) | |
| wsh_pt <- wsh$watersurfaces_polygons %>% | |
| filter(polygon_id %in% check_overlap_1$polygon_id) %>% | |
| st_point_on_surface() | |
| compare_refpoint <- wsh_pt %>% | |
| st_drop_geometry() %>% | |
| mutate(x_new = st_coordinates(wsh_pt)[,1], | |
| y_new = st_coordinates(wsh_pt)[,2]) %>% | |
| left_join(check_overlap, by = "polygon_id") %>% | |
| left_join(refpoints_previous %>% | |
| rename(polygon_id_previous = polygon_id), | |
| by = "polygon_id_previous") %>% | |
| mutate(distance = round(sqrt((x_new - x) ^ 2 + (y_new - y) ^ 2), 3)) |
|
I applied the updates from PR #79 here as well. Updated compiled HTML: update_watersurfaces_refpoints_interim.html.zip |
This project is a sibling to the main version of
update_watersurfaces_refpointswith some alterations due to the specifics of interim versions. See PR #79 for more background regarding this bookdown project.See here for differences relative to PR #79.
This new data source is meant to be stored separately at Zenodo, just like other interim versions.
Compiled HTML: update_watersurfaces_refpoints_interim.html.zip