Open tim-salabim opened 7 years ago
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.
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.
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.
There's no rush. This is surely not a must-have but a nice-to-have feature
We could easily code up a simple multi-user edit session also with Shiny.
I am not exactly sure what you mean?
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.
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.
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.
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.
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
.
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.
Is this approach CRAN conform?
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
.
Sweet, then I think this is a good approach. A suitable warning that for this particular piece geojsonio
is needed should suffice.
What projection
should we assume? mercator?
Yes, I guess web-mercator makes sense as things will look similar to what's been edited on the map.
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.
L.D3SvgOverlay
.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.
Ok, I think I can get on leaflet in < 1 hour, so going to try to do really quick poc.
added both playback to pull #38
try with
library(mapview)
library(mapedit)
editMap() %>% mapedit:::playback_lf()
editMap() %>% mapedit:::playback()
just made bug fixes and submitted + merged pull. Let me know how it works. Thanks!
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)
I should have warned that for some reason d3v4
does not work well with RStudio Viewer. I will change to open in browser window.
I see! Confirmed, it works in the breowser. Thanks, this is awsome!
could this also work for editFeatures
?
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.
@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.
No objections! It is definitely desirable to have the map background. Ideally, as in editMap
, a user-defined map.
Re playback with editFeatures
could we utilise the @object
slot in mapview
?
Sorry, I am not sure I understand. Would you mind clarifying?
sorry, on second thought, I think this is not a solution for knowing the original sf
object. My bad.
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...
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.
@timelyportfolio I really like the idea of the flubberized playback. In a scenario where person A does:
and then sends
edited.rda
to person B, person B could then ideally simply use:to get a quick impression of what has been done by person A.
Also, I think this would be a great show-off for the conference talk :-)