osmdata | R package for downloading OpenStreetMap data | Map library

If I understood correctly the issue, it seems like the NA in the raster are not completely transparent. See if in scale_fill_viridis_c changing to na.value = NA does what you're looking for.

OSM works in lat-lon, which means EPSG:4326. You need to transform the coordinates accordingly. You also don't need raster::extent(); sf::st_bbox() will be sufficient in this use case.

Or in your context consider this code; as this is only a toy example I am not using the whole NC state, but a single county (otherwise errors on timeout may occur, which would be a separate kind of a problem - this question is about bounding boxes).

One option to consider is to bind a popup to marker click via Marker.bindPopup method. In terms of react-leaflet library, GeoJSON component exposes onEachFeature event which gets called on each feature and where popup could be initialized.

Here is a modified Hospitals component which demonstrates how to bind a popup to marker click:

As I wrote in the comment, I would suggest the following approach if you need to run several queries for OSM data that belong to the same geographical area.

First of all, load packages

I solved it by using the index in the last column in data.frame as index for the paths vector

It seems like getting the xml data into another format is taking a long time. Instead of using xml, asking overpass to return an sf object and using that might be quicker. The sf object can then be manipulated & used by the sfnetworks package to get a network, while retaining the spatial aspects of the network. Weights can be added by functions from sfnetworks (or tidygraph) packages.

I think the code below focuses on taking care of the speed and the edge weight problems. Other problems, like finding the nearest nodes or edges, can be solved using the functions of the sf package, but are not addressed. Otherwise this becomes more than a one-off SO question.

The speed might be able to be increased, at the cost of spatial accuracy, by using st_simplify for the edges. One problem with this approach is that stnetworks places a node where each linestring meets another. The data returned often has a single roadway split into multiple linestrings. As an example, see two longer roads in yellow on the edges plot below. Probably a solvable problem, but may not be worthwhile in this case.

I can not help you with the timeout on a historic datetime; there may be a server side issue for all that I know (I get the same error, and your construction of the argument seems to follow documentation).

Regarding the other issues:

When working in the world of {sf} I suggest to download your data via osmdata_sf() call; it will be good for your sanity if you avoid mixing sf and sp worlds unless absolutely necessary.

The returned object will contain not only lines, but also points, polygons and (in your case empty) multi-type objects.

When working with cycle paths just select the osm_lines object to a new variable; it will contain Sevilla bike paths with geometry of type linestring.

After checking it visually you can now save it as a ESRI Shapefile; note that this is an ancient file format, based on Ashton Tate dBase IV (a DOS program for Pete's sake :) and as such allows data column names of only limited number of characters, hence the warning.

The osmdata package follows the same hierarchical structure as the Open Street Map data themselves. If you look into your data a bit further you'll see the following:

The solution is to make a transformation to the object's coordinate system. As it's shown in the following: