Reconsider applicability of `@srrstatsNA` standards

[cforgaci]

This is an issue raised as part of ropensci/software-review#718

According to @atsyplenkov,

Some [@srrstatsNA-tagged standards] could become applicable if the package’s scope or claims change, for example:

• G1.5 / G1.6 if future versions begin making explicit performance claims or if alternative implementations become available for benchmarking.
• G5.7 if the authors decide to add performance/scale expectations and corresponding tests (even if only as extended tests).
• G5.9 if any stochastic components are introduced (for example randomised sampling/initialization).

According to @mpadge,

The following standards currently deemed non-applicable (through tags of @srrstatsNA) could potentially be applied to future versions of this software:

• G2.6 about pre-processing one-dimensional inputs. Many inputs expect single parameters, and these are indeed one-dimensional (especially in R where "everything is a vector"). The example in the Stats Dev Guide refers to the units package, which I think should be used here, particularly in defining the various buffers. See below for some of my concerns in that regard.
• G2.9 about issuing messages for type conversion including metadata. Coordinate systems allow explicit control throughout, and default to convenient UTM zones, but I think that leaves a lot of scope for issuing conversion messages to help users understand what might be happening. I also think that if units are used like I suggested above, then conversions might be even more useful, for example by permitting buffers to be specified in different units (distances and arc degrees, for example).
• G2.14 seem like they should be applicable. Although most operations are purely geometric - which is part of what makes the package so strong! - some procedures depend on more than just geometry. There are a lot of implicit NA-handling routines hidden in the external calls, as this code tries to demonstrate, using the default data from the main delineate() example:

network_edges <- dplyr::bind_rows(osm_data$streets, osm_data$railways)
network <- as_network(network_edges)
edges <- sfnetworks::activate(network, "edges") |> sf::st_as_sf()
t0 <- table(edges$type)

network_edges$type[sample(nrow(network_edges), size = 100)] <- NA
network <- as_network(network_edges)
edges <- sfnetworks::activate(network, "edges") |> sf::st_as_sf()
t1 <- table(edges$type)

Those give different values, as expected, but everything runs silently. That's just one place in the code where missing values do indeed effect what happens. Since it is entirely possible for users to submit their own OSM data to any routines, missing values may arise at any stage, and so messages can -- and I'd say should -- be issued. Even better would be giving people an ability to sensibly replace or impute missing values.

• G5.6 Parameter recovery tests are implemented anyway, for example in this test via the par = res parameter, which is a definitive tolerance. Lots of other places too.

• G5.7 As mentioned in rcrisp: Automate the Delineation of Urban River Spaces ropensci/software-review#718 (comment), some kind of demonstration of scaling would really help. The algorithm sometimes seems quite slow, and I suspect scaling with data size may be strongly non-linear. It would really help people to know what to expect. And once you've gone through some process of documenting that, putting in a few concrete tests should be straightforward.

• SP2.0 is already complied with; it just says software should "*accept input of [explicit spatial] classes", which it does.

• SP2.5a - See comments below on ways I think this package would benefit from having its own class.

• SP5.0, SP5.1, SP5.2 could be applied in a way that would make the package far easier to use, as described below.

• SP6.1b seems applicable, because most algorithms presume planar coordinates, and so will yield inaccurate results in anything else (spherical or elliptical). That could easily be tested.