playback function about mapedit

[timelyportfolio]

Ok, I think I can get on leaflet in < 1 hour, so going to try to do really quick poc.

[timelyportfolio]

I agree this is nice functionality and makes for a good demo. Beyond flubberizing, I could enivison some sort of diff map, using colors, alpha, and other styling to demonstrate changes. Not sure we will have time for a full implementation by useR but something we could explore as a prototype.

[tim-salabim]

Yip, prototype sounds like a great idea! Even one that only does one thing would be enough. It may just spark enough feedback to collect for further implementation.

[timelyportfolio]

I will need to think through add and delete in a flubber context. Also will need to make sure I join properly. @tim-salabim, eventually, might be neat for you to send me a fake edit session.

[tim-salabim]

There's no rush. This is surely not a must-have but a nice-to-have feature

[timelyportfolio]

We could easily code up a simple multi-user edit session also with Shiny.

[tim-salabim]

I am not exactly sure what you mean?

[timelyportfolio]

Sorry if I wasn't clear. I meant we could we make a shared editing session in which we collaboratively edit a map.

Try this https://bl.ocks.org/timelyportfolio/cd81d81edf917dc711cfc4b2b4aa8bbf out as a little demo. Will need to work out base map and a lot more, but hopefully gets point across of playing back an editMap(). We could also do something similar without the interpolation with leaflet/mapview and shiny.

[tim-salabim]

In case we could wrap that in a function, say playback, that takes a sf object, checks for recorder attribute and if present returns such an animation, I think that would be great as a prototype even without any map background for starters.
I am still not sure what you mean by "a shared editing session in which we collaboratively edit a map"? I am assuming you mean recording of applied changes across multiple editing sessions by potentially multiple people in sequence? Or do you mean a session where multiple people work simultaneously? I wouldn't see a good use-case for the latter, but the former is definitely something that has value.

[timelyportfolio]

I meant the latter, and even if there was a lot of value, the infrastructure involved would make it out of scope for mapedit. I just thought it would make for a nice demo, but given the usual wi-fi constraints at a conference, I agree it is not worth it.

In terms of multi-session sequential history, I wonder if we should wrap the return list with recorder attribute as a s3. However, the leaflet ids would not sync, so might get tricky.

[tim-salabim]

For now I guess the attribute approach is good, as it still preserves the sf class. If we later on find that this is something that people really use very often then it will make sense to re-think the whole approach but for now I think the recorder implementation is fine as it is. If a prototype playback function is not too much of a hassle, then I think it is well worth providing it (maybe unexported), if it is a lot of work then I wouldn't put too much focus on.

[timelyportfolio]

I would prefer not to add a d3r dependency or add local d3 JavaScript in the package. I could write unexported and then just insert remote JavaScript in tags$head(tags$script()). That should suffice. Let me know if you see problems with this. I will add momentarily.

I will also try to think through how we might playback with shiny.

[timelyportfolio]

I just realized we also need geojsonio. Instead of adding as a dependency, I will check with requireNamespace and bail with warning if geojsonio not available.

[tim-salabim]

Is this approach CRAN conform?

[timelyportfolio]

Yes, it has passed CRAN in other packages I have made. Adding geojsonio to enhances should do the trick and not require a mapedit user to install geojsonio.

[tim-salabim]

Sweet, then I think this is a good approach. A suitable warning that for this particular piece geojsonio is needed should suffice.

[timelyportfolio]

What projection should we assume? mercator?

[tim-salabim]

Yes, I guess web-mercator makes sense as things will look similar to what's been edited on the map.

[timelyportfolio]

Also, if we wanted to get real fancy, we could take this in many directions, but of course will require time, and I am guessing this is lower priority.

• We could add to a leaflet map - might not be too difficult if we can use L.D3SvgOverlay.
• We could provide something like a marble diagram ( see example ) for more granular playback.

[tim-salabim]

I think for now (i.e. useR!) it would be enough to highlight that we have something in the pipeline in this direction and show a first (even alpha-state) implementation. Hopefully we will this way gather some feedback and then take things from there. So, a rough function that animates changes on a white background is enough for now in my opinion.

[timelyportfolio]

added both playback to pull #38

try with

library(mapview)
library(mapedit)

editMap() %>% mapedit:::playback_lf()
editMap() %>% mapedit:::playback()

[timelyportfolio]

just made bug fixes and submitted + merged pull. Let me know how it works. Thanks!

[tim-salabim]

For both playback functions I only see the stuff draw in the first instance but there is no animation of any subsequent edits (i.e. moving vertices around)

[timelyportfolio]

I should have warned that for some reason d3v4 does not work well with RStudio Viewer. I will change to open in browser window.

[tim-salabim]

I see! Confirmed, it works in the breowser. Thanks, this is awsome!

[tim-salabim]

could this also work for editFeatures?

[timelyportfolio]

If I understand correctly, I think so, but we would have to know the original sf maybe as argument to the playback function. I don't think it would be good to store the whole original sf in our recorder attribute. I will also need to think through the join in the JavaScript function.

[timelyportfolio]

@tim-salabim going to remove playback and just pursue playback_lf as playback unless you have objections. Also, getting close to a version sort-of-working with editFeatures() recorded session.

[tim-salabim]

No objections! It is definitely desirable to have the map background. Ideally, as in editMap, a user-defined map.

[tim-salabim]

Re playback with editFeatures could we utilise the @object slot in mapview?

[timelyportfolio]

Sorry, I am not sure I understand. Would you mind clarifying?

[tim-salabim]

sorry, on second thought, I think this is not a solution for knowing the original sf object. My bad.

[tim-salabim]

Ok, one last thing that would be really nice in playback (especially for editFeatures) is a grey static version of the original feature, so that comparisons to the original are made easy. Sorry for coming up with these things one after the other, but this is something that I am only exploring as we go along...

[timelyportfolio]

Great idea, I will try this out. Here is where mapview slot might be helpful I think.

Since it seems I was not missing anything in the prior discussion, I will elaborate on my answer for posterity.
In general, most of the properties/attributes are lost in the final graphical output when using mapview/leaflet. In mapview they still often exist in the popup table, but this information is really hard to parse. I have found that id can be hacked with a list containing a full set of information. I worry though that this method might cause downstream problems even though I have not found any yet.