Skip to content

Conversation

@florisvdh
Copy link
Member

@florisvdh florisvdh commented Sep 29, 2025

This project is a sibling to the main version of update_watersurfaces_refpoints with 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

@florisvdh florisvdh requested a review from ToonHub September 29, 2025 17:00
```

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.
Copy link
Contributor

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

Copy link
Member Author

@florisvdh florisvdh Oct 24, 2025

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_id values 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 with watersurface_hab will provide correct reference points.
  • no discarding happens of polygon_ids that do not exist in the corresponding version of watersurfaces_hab, since no conflicts are expected (the same id being used for different things). Hence we already had backward compatibility with older watersurfaces_hab versions. In the case of the interim version, the backward compatibility holds for the interim and the regular versions together as polygon_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)
```

Copy link
Contributor

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.

Suggested change
```{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))

@florisvdh
Copy link
Member Author

I applied the updates from PR #79 here as well.

Updated compiled HTML: update_watersurfaces_refpoints_interim.html.zip

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants