mark padgham

Yes indeed that would be useful @Mashin6, and better in all ways. One way to achieve it might be to introduce yet another `trim` function that gets piped *before* the...

Great use case. This is definitely the intention of `osmdata_sc() -> dodgr`. The first part is done, and is generally several times faster to extract than `osmdata_sf()` (ref issue #148)....

I intend to soon start thinking about this in a structured way in [this exploratory repo](https://github.com/mpadge/osmnx-vs-osmdata). I'll update this issue as thoughts and insights progress there ...

I'll trust your judgment on that one, and correspondingly be happy to integrate in `osmdata`. It's all implicitly integrated with the new [`dodgr::weighting_profiles` values](https://github.com/ATFutures/dodgr/blob/master/data-raw/pkg-data-scripts.Rmd). It's still just a messy script,...

This must be postponed until everything has been `silicate`-erized via #158

Thanks @stragu, this will all start coming together in a branch after I've addressed #252. It's going to be difficult to do this well, but it is clearly pretty important,...

Thanks @vanhry, that's an interesting question. timestamps of individual objects are not by default delivered by the overpass server, but can be extracted as ["metadata"](https://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#out) as in your query above....

Thanks @Mashin6, and apologies for the delay in responding here. It's not a bug, it reflects the operation of the `exclude` parameter in [the `trim_osmdata()` function](https://docs.ropensci.org/osmdata/reference/trim_osmdata.html): ``` r library (ggplot2)...

Yeah, right, it's an issue with how to interpret multipolygons. The trim operation for Colchester is extracting the internal component of the multipolygon. In cases where internal components of multipolygons...

@Mashin6 The above commit improves the `trim_osmdata()` function, but your issue still remains. It is, however, due to a bug in the OSM data set, as this `reprex` illustrates: ```...