support MULTILINESTRING about mapedit

[tim-salabim]

@timelyportfolio for re-casting to MULTILINESTRING you can use do.call(c, lapply(split(tr2, tr2$edit_id), st_combine)).

[timelyportfolio]

@tim-salabim, thanks for that bit of code. c will work well in this scenario. In a case with mixed types, won't st_combine convert everything to MULTI*? I will test to make sure that this will not interfere with our cast back to original (which I think is a very nice feature).

[timelyportfolio]

Here is my test sf (challenge) with mixed types to get working with edit.

# since we have discovered a way to go from MULTILINESTRING
#   to a group of LINESTRING and back, now the trick will be
#   to perform this magic in a sf with mixed types.
#   let's make a mixed type sf
mixsf <- st_sf(geometry = c(
  st_geometry(franconia[1:2,]),
  st_geometry(trails[1:4,]),
  st_geometry(breweries[1:5,])
))

[tim-salabim]

As long as it's not in a GEOMETRYCOLLECTION, st_dimension will show us the different types.

st_dimension(mixsf)
[1] 2 2 1 1 1 1 0 0 0 0 0

When encapsulated within a GEOMETRYCOLLECTION we need to st_cast(gc) first in order to get the individual components.

[timelyportfolio]

@tim-salabim, I probably need to clear my head, and I'm guessing the answer is obvious but why does this not work? Never mind, as I thought, was very dumb on my part. I need to st_transform.

library(sf)
library(mapview)
library(mapedit)

mixsf <- st_sf(geometry = c(
  st_geometry(franconia[1:2,]),
  st_transform(st_geometry(trails[1:4,]), crs=4326),
  st_geometry(breweries[1:5,])
))

mapview(mixsf)

The code above will not render the lines.

[tim-salabim]

Yeah, that one has caught me several times too. I left it delibarately in non-longlat as a gentle reminder that not all data comes in longlat...

Though this brings up a good point for mapedit *Features. We need to decide what we do with data supplied in non-longlat. mapview::checkAdjustProjection will ensure that data is projected correctly for rendering and drawn/edited features are currently returned in longlat. Should we transform back to initial supplied CRS? Or simply return longlat with a warning?

[timelyportfolio]

@tim-salabim looks like the easy solution is to use editor="leafpm", since Leaflet.pm handles MULTILINESTRING.

library(sf)
library(mapview)
library(mapedit)

editFeatures(trails[4,], editor="leafpm")

However, I'm not sure this is an acceptable solution for the project.

[timelyportfolio]

0.5.0 will merge in support for leaflet.pm using the new package leafpm. This handles MULTILINESTRING well, so I will consider this issue closed.

Please reopen if anyone would like to discuss further.