Why separating sf objects in osmdata object?

[niklaas]

First and foremost, thanks a lot for providing this package. It makes working with OSM data quite handy. In my projects I mainly use osmdata_sf, building the Overpass query by myself. This is mainly because the requests are a bit more complex and I prefer filtering on the server side (if I can).

I keep wondering why osmdata_sf separates sf objects in $osm_*. Is this done on purpose i.e., a design principle, or due to technical limitations? I have been working on a function that combines the sf objects into a single one of type GEOMETRY, which is not that difficult to implement. I keep myself asking when I'll run into a dead end, probably starting to understand why you separate the objects in your package in the first place.

Additionally, is there need for further helper functions that make accessing popular features (such as bus/metro/railway stations/routes, shops, etc.) easier? So any user unfamiliar with the Overpass API would gain access to the data -- at least to some extent. I thought about implementing these functions. I would either create my own R package for them (based on osmdata) or submit them to osmdata, if you think they would enhance the package.

[mpadge]

Thanks @niklaas for your interest in the package! I'd be interested to know what kind of queries you build that might lie beyond the osmdata construction. The value_exact and key_exact parameters (see vignette) should cover most overpass filtering requirements. The only hole I am aware of is recursion, and I'd be keen to know whether that's part of your reason for building queries directly. (See also #55)

As for the separation of objects - that is an attempt to interpret the OSM data format in OGC Simple Features (SF) terms. That's impossible to do strictly (there used to be a helpful discussion about this on the osm wiki, but that's been removed), but osmdata is at attempt to systematically translate OSM data into SF terms. The motivation behind this is described in the second vignette. The separation also reflects exactly what GDAL does (including via the sf package), although osmdata differs somewhat as also noted in the 2nd vignette.

Simply packing all as a single type would require it to be a GEOMETRYCOLLECTION, but that would almost immediately prevent most users from being able to unpack everything into desired object classes (points, lines, polygons, and the rest). In short: the $osm_ objects reflect an admittedly (yet unavoidably) somewhat subjective attempt to best map OSM data structrures on to the OGC SF. OSM does have points, lines, polygons, multilines (effectively), and multipolygons (effectively), and so these really are natural types to represent OSM data.

Now, regarding the helper functions: Yes, totally agree, and yes, please submit them to osmdata! That would be great. osmdata emerged out of initial osmplotr code, and the latter does implement a few "shortcuts" for common objects in these lines. I always intended to do a similar thing for osmdata, but didn't get around to it yet. I'd appreciate any suggestions or help at all in that regard! (And feel perfectly free to directly copy the osmplotr approach if you want, or to implement any alternative you see fit.)

[niklaas]

Thanks a lot for your sophisticated reply. I hope I will find more time to provide some code examples explaining my thoughts next weekend; for the moment, the following shall suffice:

I prefer providing my own queries because this way I can already filter on the server side. Reducing the amount of response data greatly shortens converting it to sf. (At least this is what I experienced by simple observation. I haven't examined or measured execution times in detail.) For example, as far as I know, with osmdata I can only select by bounding box and not by around i.e., finding features within the radius of a specified center. (I already thought about extending opq() in that regard, by the way.)

Regarding the separation of objects: This came to my mind when I started implementing a function that queries for bus stations. In OSM some of them are points, others are areas (ways). And bringing $osm_points and $osm_polygons together was quite tedious (I'm not satisfied with the result still). I haven't given it a lot of thought yet but my feeling said that handling OSM data must become (even) more convenient in R. This is not to say that your package doesn't already help a lot! It's just that I see great potential in analysing OSM data with R -- it's a treasure we still have to dig up. Most probably osmdata_sf() already is the right way to go and it just needs some helper functions.

Thank you for mentioning osmplotr. The package is new to me but looks worth experimenting with.

I hope I can provide better examples soon -- and eventually help to extend osmdata, at least a bit.

[mpadge]

@niklaas That's a very convincing reason to write your queries directly! But note issue #74 - i just have to write a parser for the OSM pbf format and then all data will be delivered that way. That should make things between 10 and 100 times faster!

In the meantime, I'll close this issue now, but hope for more input from you soon. In particular, if you could provide some examples of the difficulties you have in combining objects, we can see how we could adapt osmdata to make life easier for you.