Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

how to visualise routes #7

Open
mpadge opened this issue Mar 30, 2017 · 4 comments
Open

how to visualise routes #7

mpadge opened this issue Mar 30, 2017 · 4 comments
Assignees

Comments

@mpadge
Copy link
Contributor

mpadge commented Mar 30, 2017

The slowness of shiny/leaflet will eventually be a problem. Nice example of potentially alternative approach?, or maybe convert sf objects to raster prior to overlaying on leaflet.

@karpfen
Copy link
Member

karpfen commented Mar 30, 2017

I think the rasterizing would be a really good approach. But fasterize doesn't support linestrings so far. I tried raster::rasterize as well, but that's just way too slow. Also, I'd really like to keep the non-CRAN dependencies at a minimum if possible.

I didn't get iheatmapr to do what I want it today, but I'll try some more tomorrow or so. But there's also the CRAN issue with that.

One more possible solution I could think of would be to just display the n features with the highest probability. Or maybe all features above a certain threshold. What do you think about that?

@mpadge
Copy link
Contributor Author

mpadge commented Mar 31, 2017

Oh yeah, of course fasterize is just about polygons, because otherwise you have to arbitrarily decide how thick a line is. That package wouldn't necessarily be a CRAN issue, because i guess Noam will get it there pretty soon, or else we could just steal his code (with his approval). But maybe not just a good solution.

Thresholding will likely be necessary at some stage regardless, but can't be relied upon just to speed up plotting. We'll have to find another solution ... Can you have a look into the shiny/leaflet code to see exactly what it's doing that might make it so slow? Once we know that we'll have a better idea how to speed it up - you could use profvis, as described here to help you find which parts of the code are slowing things down so much.

@mpadge
Copy link
Contributor Author

mpadge commented May 30, 2017

Andi,
Not that you should or likely can incorporate this into your package, but I submitted bikedata to CRAN today. The vignette includes this nice graphic which illustrates yet another approach to standard shortest-paths in R. The magic happens in the stplanr::sum_network_links() function.

Two ideas directly follow:

  1. This code might be worth examining for ideas ...
  2. This also seems to represent current state-of-the-art for generating such things in R, and you'll note that it still takes a fair degree of hefty coding (and is sp-reliant, rather than sf, so is slower than need be). This could serve as a nice benchmark against which to demonstrate the superiority of osmprob.

@karpfen
Copy link
Member

karpfen commented May 30, 2017

Holy crap, you're really pumping out those packages at the moment :)

ad 1. I will! Actually, I've already made a very similar leaflet map in this style and was going to use it anyway. But I also want to generate some static maps somehow, so this could be good for that.

ad 2. Also very good! I've been looking for comparable things to benchmark.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants