Add vec_equal support to wk_wkb vectors

[anthonynorth]

Adds vctrs::vec_equal() support for wk_wkb vectors.

Closes #181

[codecov-commenter]

Codecov Report

Patch coverage: 100.00% and no project coverage change.

Comparison is base (e3d4efb) 99.03% compared to head (ca53871) 99.03%.

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #183   +/-   ##
=======================================
  Coverage   99.03%   99.03%           
=======================================
  Files          81       81           
  Lines        5888     5918   +30     
=======================================
+ Hits         5831     5861   +30     
  Misses         57       57           

Impacted Files	Coverage Δ
src/init.c	100.00% <ø> (ø)
R/pkg-vctrs.R	100.00% <100.00%> (ø)
R/wkb.R	93.33% <100.00%> (+0.15%)	⬆️
src/vctr.c	100.00% <100.00%> (ø)

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[paleolimbot]

Thank you! All just details 🙂

Is it worth exposing the "convert to hex" in any other way? It is probably useful in other contexts as well...maybe wkb_to_hex() or something?

[anthonynorth]

Is it worth exposing the "convert to hex" in any other way? It is probably useful in other contexts as well...maybe wkb_to_hex() or something?

It could be useful. I can add wkb_to_hex to this PR, or a separate PR if you'd like me to do it.

[anthonynorth]

Should 2 identical features with different endianness be considered equal? Should vctrs::vec_order(wkb) be endian-dependent (which it currently is)?

# remotes::install_github("paleolimbot/wk#183")
library(wk)

points <- wkt(c("POINT (1 1)", "POINT (2 2)"))
points_le <- wk_handle(points, wkb_writer(endian = 1))
points_be <- wk_handle(points, wkb_writer(endian = 0))

vctrs::vec_equal(points_le, points_be)
#> [1] FALSE FALSE
vctrs::vec_order(points_le) == vctrs::vec_order(points_be)
#> [1] FALSE FALSE

^{Created on 2023-07-11 with reprex v2.0.2}

[paleolimbot]

Regarding wkb_to_hex()...I'm happy to review that as part of this PR if you'd like to add it and test it (otherwise feel free to omit but open an issue so I don't forget to add it before the next release).

Regarding vec_equal() with different endians...I would personally consider the current behaviour (point_le != point_be) sufficient. If you truly need geometric equality, you will need a geometry engine (e.g., geos_equal())...using == with wkb() or wkt() will always miss some things a user might consider "equal".

[paleolimbot]

Just one nit! Thank you!

[anthonynorth]

I've exported wkb_to_hex() -- but I haven't rebuilt package documentation.

[paleolimbot]

Thanks! (FWIW, it's usually good practice to rebuild the documentation yourself)