overpass_query doesn't seem to return polygons when it should about osmdata HOT 7 CLOSED

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

from osmdata.

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.

from osmdata.

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

from osmdata.

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?

from osmdata.

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 ...)

from osmdata.

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.

from osmdata.

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)

from osmdata.