search

r-spatial / mapedit

Interactive editing of spatial data in R
https://www.r-spatial.org/r/2019/03/31/mapedit_leafpm.html
Other
218 stars 33 forks source link

generalize editMap function #12

Open timelyportfolio opened 7 years ago

timelyportfolio commented 7 years ago

As suggested by @tim-salabim on Twitter, generalize the editMap function to use more than just Leaflet.Draw.

edit(<object>, editFunction())
#As in 
mapedit::editMap(leaflet_map, leafletDraw())?
tim-salabim commented 7 years ago

@timelyportfolio this twitter comment was basically a "let's aim high" call. What I imagine is a generalized framework that would set up an edit() function for all sorts of htmlwidget based vis packages which lets the user set up a editing app that will be useful for manipulating the respective visualisations provided by the htmlwidget. In our case we are dealing with leaflet maps (the objects) and leafletDraw() (the draw function). Provided something similar to leafletDraw is available in any other arbitrary htmlwidget based vis package, the skeleton edit app could then be created automatically (with certain expectations and defaults). So basically an app creator.

This would be useful also for future maintenance of mapedit as we could more easily add new functionality.

This would also address RConsortiums bid to create a generalised framework for other htmlwidgets.

tim-salabim commented 7 years ago

I guess your Igraph example is proof that this could work. https://gist.github.com/timelyportfolio/94c44959cf73e96a12ee2e194aaaaf2a

Yet, I think this would actually need to be best hosted in a different package.

timelyportfolio commented 7 years ago

I love the "let's aim high" spirit. I would think that the select/query and edit attributes objectives would be more applicable than the CRUD for other htmlwidgets. Also, based on observations of current htmlwidgets, my guess is very, very few would take the next step to provide an edit function as sophisticated as Leaflet.Draw. However, it should not be overly difficult to keep in mind as we make these functions. I would like to focus on our narrow scope though at the outset, since time is ticking quickly. The igraph is intended to show that the flexibility of the leaflet mechanism with L.CRS.Simple offers lots of potential outside of the geospatial world. So, I guess there are two opportunities for generalization in this one function. I will try to push the boundaries with each of our defined objectives.

@tim-salabim, I really appreciate your communication. Thanks.

tim-salabim commented 7 years ago

I totally agree that focus should be on the mapedit narrow scope. If we can keep a general approach in the back of our heads while implementing things that's enough. I just really like the idea of functional programming and flexible and versatile building blocks. So I think setting the mechanism semantics to accommodate a more general implementation would be enough for now.