osmdata lacks a vignette

[Robinlovelace]

Solution: @masalmon myself and probably others will write one (Mark please digitally meet Maëlle).

[maelle]

Nice to e-meet you, @mpadge and thanks @Robinlovelace for the introduction!

[Robinlovelace]

Any suggestions on this @mpadge? My first question is: how stable are the function names and behaviour?

[mpadge]

Short answer: NOT. I'd suggest we first need to resolve the all-important Issue #1, for which I have to largely accept responsibility. I'll let you know here when things are name- and type-stable, and we can head off with a vignette. Of course, much preparatory drafting could nevertheless be done absent that, so feel free to head off regardless. Otherwise, I'll do my best to get it to a stable state within the week, and will then give a heads-up here to get the vignette rolling...

[mpadge]

Note also that the overpass directory still exists only because it holds documentation that Bob was obviously intending to use for a vignette - once that's been gleaned, then please delete this entire directory!

[mpadge]

I've sketched an osm-to-sf vignette. The major thing this now needs is filling out with some concrete examples, which can now be done because sf implementation is now finished!!!

(and i've now assigned you Robin to finish this off ...)

[maelle]

Nice work! :tada:

[maelle]

When the vignette is finished the package could get a blogdown website?

[mpadge]

Thanks @masalmon ! an epic amount of coding! Some kind of website would be great of course - we can all work together on that later. github pages are also pretty straightforward.

[maelle]

blogdown is really the easiest thing, I promise :grin:

[mpadge]

totally happy to believe you! more than totally happy to hand that responsibility over to you - thanks!

[maelle]

Deal!

[maelle]

I meant pkgdown the whole time :upside_down_face:

[mpadge]

Vignette roughly sketched out - anyone want to have a look, suggest, change, improve things? @Robinlovelace ? @masalmon ?

[maelle]

I'll try to have a look later this week, many thanks @mpadge ! :tada:

And if I don't do it this week then in two weeks :-)

[Robinlovelace]

On the to-do list.

[mpadge]

@Robinlovelace Thanks for vignette work thus far! Note that i've moved bob's previous overpass-refs.bib file to the vignettes dir, and that these are indeed good references to cite somewhere in the vignette

[mpadge]

@Robinlovelace Thanks heaps for the stellar vignette work! I just did a slight tweak, and would like to request one further change from you:

I think it would be better to move from the initial query construction on lines80-81 straight onto the core osmdata functions. Query translation with qry_to_string (which should maybe be re-named query_to_string, right?) would then be better placed at the end of the section on overpass queries, where it can be mentioned that the results of qry_to_string can be pasted directly into overpass-turbo.eu.

I'd also prefer ditching the QGis stuff, especially because the figure detracts from the main focus, and only a minority of people (namely, ubuntu users) will even recognise what it is.

Other than that, I'd say only two major remaining tasks:

1. Expand the final section on recursive searching; and

2. Rewrite the almost unintelligible second dot-point under osmdata_sf(), and likely link that to the previous point.

Perhaps a larger re-structure is in order, firstly just briefly showing osmdata_sf() functionality, secondly introducing recursive searching, and thirdly doing a direct comparison with GDAL/sf.

[Robinlovelace]

I'm up for that, sounds like a plan. Any pointers on recursive search though?

I was also thinking it would be good to reproduce examples in the docs on the osm wiki on overpass, e.g.:

<osm-script output="json">
  <query type="relation" into="hr">
    <has-kv k="route" v="hiking"/>
    <has-kv k="name:de" v="Meraner Höhenweg"/>
  </query>
  <union>
    <item set="hr"/>
    <recurse from="hr" type="relation-way" into="hrp"/>
    <recurse from="hr" type="relation-node"/>
  </union>
  <print mode="body" order="quadtile"/>
  <recurse from="hrp" type="way-node"/>
  <print mode="skeleton" order="quadtile"/>
</osm-script>

Think there's merit in reproducing such examples with reference to the osm wiki.

Contributing to the vignette also raised these questions:

• How to search for a range of values for a particular key, e.g. highway="cycleway|footway"
• How to search for a range of values for a couple of keys, e.g. highway="cycleway|footway" | bicycle = "yes"
• How to search for relations

I currenty don't know how to do these things myself so input appreciated on those issues.

[mpadge]

Okay, that provided the perfect and necessary motivation for me to implement a c method for osmdata objects. Check this out:

> q <- opq ("Seville")
> q1 <- add_feature(q, key = "highway", value="cycleway")
> d1 <- osmdata_sf (q1)
> q2 <- add_feature(q, key = "highway", value = "footway")
> d2 <- osmdata_sf (q2)
> q3 <- add_feature(q, key = "bicycle", value = "yes")
> d3 <- osmdata_sf (q3)
> d1; d2; d3
Object of class 'osmdata' with:
                 $bbox : 37.3002036,-6.0329182,37.4529579,-5.819157
        $overpass_call : The call submitted to the overpass API
            $timestamp : [ Mon Feb 27 16:25:45 2017 ]
           $osm_points : 'sf' Simple Features Collection with 6981 points
            $osm_lines : 'sf' Simple Features Collection with 471 linestrings
         $osm_polygons : 'sf' Simple Features Collection with 4 polygons
       $osm_multilines : 'sf' Simple Features Collection with 0 multilinestrings
    $osm_multipolygons : 'sf' Simple Features Collection with 0 multipolygons

Object of class 'osmdata' with:
                 $bbox : 37.3002036,-6.0329182,37.4529579,-5.819157
        $overpass_call : The call submitted to the overpass API
            $timestamp : [ Mon Feb 27 16:25:47 2017 ]
           $osm_points : 'sf' Simple Features Collection with 9853 points
            $osm_lines : 'sf' Simple Features Collection with 1574 linestrings
         $osm_polygons : 'sf' Simple Features Collection with 114 polygons
       $osm_multilines : 'sf' Simple Features Collection with 0 multilinestrings
    $osm_multipolygons : 'sf' Simple Features Collection with 9 multipolygons

Object of class 'osmdata' with:
                 $bbox : 37.3002036,-6.0329182,37.4529579,-5.819157
        $overpass_call : The call submitted to the overpass API
            $timestamp : [ Mon Feb 27 16:25:50 2017 ]
           $osm_points : 'sf' Simple Features Collection with 4756 points
            $osm_lines : 'sf' Simple Features Collection with 334 linestrings
         $osm_polygons : 'sf' Simple Features Collection with 12 polygons
       $osm_multilines : 'sf' Simple Features Collection with 0 multilinestrings
    $osm_multipolygons : 'sf' Simple Features Collection with 1 multipolygons

> d <- c (d1, d2, d3)
> d
Object of class 'osmdata' with:
                 $bbox : 37.3002036,-6.0329182,37.4529579,-5.819157
        $overpass_call : The call submitted to the overpass API
            $timestamp : [ Mon Feb 27 16:25:45 2017 ]
           $osm_points : 'sf' Simple Features Collection with 19403 points
            $osm_lines : 'sf' Simple Features Collection with 2191 linestrings
         $osm_polygons : 'sf' Simple Features Collection with 129 polygons
       $osm_multilines : NULL
    $osm_multipolygons : 'sf' Simple Features Collection with 10 multipolygons

It automatically expands data.frames to total numbers of unique columns, and only includes unique features in each case. Now tell me that's not awesome!

Only implemented for osmdata_sf objects. Attempting with osmdata_sp just generates a warning that method is not implemented. I'm good with that for an initial cut.

[Robinlovelace]

That looks awsome!

[mpadge]

And now see #45 for a detailed relation example and some associated thoughts