nominatim & overpass (candidates for rOpenSci?)

Tags: #<Tag:0x00007fe4dceb34d0>

Looking for some input to stop some my head from jumbling around (and also have a question).

I’ve got two in-development packages that work with OpenStreetMap data/services:

Nominatim (https://github.com/hrbrmstr/nominatim) and Overpass (https://github.com/hrbrmstr/overpass). The former is a general search & geocoding interface (but it also returns bounding boxes for things which work well with Overpass). The latter works with the Overpass API http://overpass-api.de/ and you can see the queries/data via http://overpass-turbo.eu/ (if you’re not familiar with it).

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.

1 Like

Just a note that links within parentheses don’t get resolved to a hyperlink - see Links section at Welcome to rOpenSci Discuss

To answer your questions:

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

What are your questions?

@hrbrmstr We discussed and both pkgs seem like a good fit.

When you’re ready, submit to our onboarding repo: https://github.com/ropensci/onboarding/

Also, you said you had questions?

Aye. I’ll get them into onboarding shape. Thx.

Insofar as questions go…

First, we’re contemplating building query pipes ala
overpass query pipes? · Issue #7 · hrbrmstr/overpass · GitHub and one q was looking for
input on just how crazy to go there (the overpass API is pretty rich w/r/t
search criteria).

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

-Bob

Sounds good :thumbsup: