Before I blather on with a question, would these potentially belong in rOpenSci or would that be more for an “rOpenGeo” (there is no rOpenGeo, just positing)? If y’all think the latter I won’t pester with the question(s) that I have. If y’all think it does, I will post some questions that will impact usability of the packages.
We do have a nascent geospatial set of tools https://ropensci.org/packages/#geospatial - so we’re definitely interested in spatial tools in general (we think they’re of broad interest) - and yours in particular look potentially like a good fit. Correct me if I’m wring @cboettig@karthik@jennybc@richfitz
The second is more important (IMO). Overpass returns points (think of these
as SpatialPoints/SpatialPointDataFrames), ways (think of these as
SpatialLines/SpatialLinesDataFrames) and relations which can be like
SpatialPolygons/SpatialPolygonDataFrames but can also just be lines or
points. We’re a bit stuck on what to return from read_osm /
overpass_query. A list with points, ways and relations, each having a
Spatial object (or more in case of relations)? Just list of Spatial objects
perhaps somehow tagged as way, point or relation? Do we return it as a
geojson object ala
and let the user sort it out?
That’s a pretty big decision and it’s presently holding up the remainder of
the spatial work.
osmar - a pkg Robin suggests may be unstable & unsupported, now, returns a
list of Spatial objects. I could just mimic that, but don’t want to go in
head-first without more input.
Same as a DSL? I’m all in favor of that. I’ve done the same for Elasticsearch, where the queries can get super complex, so a DSL is kind of necessary. Although, I’ve broken off the DSL as a separate package since the DSL is quite a few functions itself - and to make the low level client and higher level DSL easier to maintain.
Do you have fxns downstream that act on the outputs of those fxns? Seems that could help in deciding what to give back. Curious what the most likely thing is that the user will do once they get data from these fxns?
All else equal, I’m in favor of a list, then attach a S3 class to it, and use a print method to hide all the complexity. Maybe returning Spatial-* classes is best since many R pkgs deal with those classes. A user could then use geojsonio or similar to convert to geojson if needed.
(Just getting back to this after a big job/company change)
Shortly after these were made, the Nominatim API changed and I need to tweak some things to get them back into shape. I’ll also work on making the changes you suggested
