Create list of key-value pairs and relation names defining osm data

[Robinlovelace]

No description provided.

[Robinlovelace]

Here's my starter for 10: https://github.com/cyipt/cyipt/blob/master/cyipt-created-data/cycling-key-values-osm.csv

[Robinlovelace]

Here are the results as an online map:

Here's the code that generated that:

b = getbb("Bristol")
q = opq(b) %>% add_feature(key = "highway", value = "cycleway")
cycleway = osmdata_sp(q = q)
sp::plot(cycleway$osm_lines)

mapview::mapview(cycleway$osm_lines, lwd = 5, map.types = "Thunderforest.OpenCycleMap", color = "black")

[Robinlovelace]

Update: we can pull in the NCN using this code:

q1 = opq(b) %>% add_feature(key = "name", value = "Atlantic Coast Route - part United Kingdom")
cq1 = osmdata_sp(q = q1)

Result:

[mvl22]

Any chance we could combine this with #9 which seems to be the same thing?

[mvl22]

NB Any approach that defines names will definitely always be wrong - that will not be comprehensive and it won't be robust.

I really would an Osmosis pipeline -based approach for extracting OSM data robustly, though perhaps the key/value pair stuff noted above is doing the equivalent thing (albeit almost certainly a lot more slowly given how optimised Osmosis is for extracting efficiently from what is a large dataset).

[Robinlovelace]

The stuff noted is just doing the same thing that osmosis would, albeit with fewer lines of code. Plus it would work on the raw .osm file I believe, right @mpadge?

[mpadge]

it's hard to directly compare osmosis and osmplotr, because osmosis processes (implicitly large) pbf files and allows extraction of key-val pairs and the like, while osmplotr uses overpass to directly extract the (generally much smaller amount of) requested OSM data and pipe it straight into R. osmosis was conceived of in days prior to efficient API servers; osmdata is in that sense a much more modern and flexible way to extract and process OSM data.

Speed comparisons also can't really be done in any sensible way, but osmdata should certainly be faster for almost all 'naive' queries - starting with nothing, and getting data from anywhere in the world with or without query parameters quickly into R. That can't be done with osmosis, because you first have to get the pbf data from somewhere, and you have to do that manually. osmdata automates the entire process, so can only be judged as 'faster' in that sense. Robustness and speed and whatever else are non-issues. osmdata is simply much easier. Oh, and also entirely platform independent, which osmosis sure ain't.

[Robinlovelace]

Many thanks for you input @mpadge, that's a great explanation of why osmdata seems like a good place to start for this. Very impressed with its performance so far and WAY easier than osmosis's fidly syntax. Does that address your concerns @mvl22?

[mvl22]

Of course, if it works best, go for it!

[mvl22]

Overpass previously has been known to be slow, because people overload it with queries for bulk amounts of data rather than focussed queries.

Also, I'm not really clear about the point on pbf data. These are available at known URLs on the Geofabrik site. It's trivial to script a download of it as part of an import routine. We certainly do as part of our journey planner import, and indeed have a matching routine to get the smallest possible downloads for the geographical areas we want to cover.

My point about R (actually Overpass) vs Osmosis was really with the assumption in my mind that in practice the full OSM data set of highway features will end up being needed, not just the small proportion that have cycling tagging on them.

[Robinlovelace]

Yes, but it's better to import the kitchen sink piece-by-piece rather than as an entire kitchen sink, taps and all. Incidentally this complete .osm file for Chapeltown Road was downloaded with osmdata. So yes it works best for our current use case and given the team's current skills at present to the best of my knowledge.

[Robinlovelace]

To clarify @mvl22 are you up for doing this. It's not the same as #9 - the code is different from the k-v pairs.

[mvl22]

My comment at

#9 (comment)

basically shows what is needed.

However, I'm not sure how to represent this as a CSV file, because for instance

Ways with highway=footway with bicycle=yes

is combinatorial so can't be presented as two columns.

[Robinlovelace]

Please add more columns, e.g. key2, value2.

Sounds promising, thanks for working on this.

[Robinlovelace]

Closing as we've got good working code for processing key-value pairs now.