overpass_query doesn't seem to return polygons when it should

[Robinlovelace]

Example, from which I was expecting to get Lovell park as a polygon as it is:

b = tmap::bb("Leeds")
q = opq(bbox = b) %>% 
  add_feature("leisure", "park")
p = overpass_query(query = q)
library(sp)
plot(p$osm_points)
mapview::mapview(p$osm_points)
plot(p$osm_polygons)

Instead I get just points of the border by the look of it:

[Robinlovelace]

Interestingly, neither does QGIS which makes me think it's an issue at the GDAL level.

Another, smaller parky example:

u = "http://overpass-api.de/api/interpreter?data=%2F*%0AThis%20has%20been%20generated%20by%20the%20overpass-turbo%20wizard.%0AThe%20original%20search%20was%3A%0A%E2%80%9Cleisure%3Dpark%E2%80%9D%0A*%2F%0A%5Bout%3Axml%5D%2F*fixed%20by%20auto%20repair*%2F%5Btimeout%3A25%5D%3B%0A%2F%2F%20gather%20results%0A%28%0A%20%20%2F%2F%20query%20part%20for%3A%20%E2%80%9Cleisure%3Dpark%E2%80%9D%0A%20%20node%5B%22leisure%22%3D%22park%22%5D%2853.794871619441025%2C-1.5554237365722654%2C53.81063582424263%2C-1.5232372283935547%29%3B%0A%20%20way%5B%22leisure%22%3D%22park%22%5D%2853.794871619441025%2C-1.5554237365722654%2C53.81063582424263%2C-1.5232372283935547%29%3B%0A%20%20relation%5B%22leisure%22%3D%22park%22%5D%2853.794871619441025%2C-1.5554237365722654%2C53.81063582424263%2C-1.5232372283935547%29%3B%0A%29%3B%0A%2F%2F%20print%20results%0Aout%20meta%3B%2F*fixed%20by%20auto%20repair*%2F%0A%3E%3B%0Aout%20meta%20qt%3B%2F*fixed%20by%20auto%20repair*%2F"
download.file(url = u, destfile = "test.osm")
psf_o = st_read("test.osm", "multipolygons")


## Reading layer multipolygons from data source test.osm using driver "OSM"
## features:       3
## fields:         25
## proj4string:    +proj=longlat +datum=WGS84 +no_defs 

Yet there are clearly more from JOSM (it doesn't even load in QGIS!):

Related to r-spatial/sf#45

[mpadge]

Yeah, I've not yet got on to full polygon testing, but shall do so sometime next week at the latest. I'll let you know.

[Robinlovelace]

Cheers, hope those test parks are useful - will be useful for my (real life!) explorations of the parks of Leeds.

[Robinlovelace]

Then it will be able to do things that sfr cannot I think... Seems even QGIS needs an intermediate sqlite stage to properly load osm data - have you seen that?

[mpadge]

Yeah, I'm poring over the GDAL code which is spectacularly well written, and it seems the speed is due to dumping the initial read straight into sqlite and then reading components from there. I've set up a direct GDAL read (in C++) to enable comparison and to ensure results for osmdata are strictly identical. (This also enables me to constantly compare output of sf, which is handy ...)

[Robinlovelace]

Awesome. Do I sense a PR into GDAL brewing so it can handle .osm files better? How about osm's .pbf format? Maybe there's a way to download data as .pbfs? All very speculative without looking at any actual code. Thanks for doing the coding btw.

[mpadge]

Finally got on to this one. The sp::SpatialPolygonDataFrame objects weren't quite being constructed properly (in Rcpp). Now they are, and it looks like this:

b = tmap::bb("Leeds")                                                               
q = opq(bbox = b) %>% add_feature("leisure", "park")                                
p = overpass_query(query = q)
sp::plot (p$osm_polygons)