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

Static mapping package? #57

Open
dblodgett-usgs opened this issue Dec 17, 2022 · 7 comments
Open

Static mapping package? #57

dblodgett-usgs opened this issue Dec 17, 2022 · 7 comments

Comments

@dblodgett-usgs
Copy link

Scanning the r-spatial list we have a clear set of slippy map community packages, but what do people recommend for static mapping? Tmap? Ggmap? Mapsf? Other? There are a few options out there and I’m wondering if one is more defacto supported as a long term dependency for r-spatial?

@Nowosad
Copy link
Contributor

Nowosad commented Dec 17, 2022

In my opinion, all of the ones below are good options:

@dblodgett-usgs
Copy link
Author

A while back, I implemented a client with prettymapr: https://github.com/DOI-USGS/nhdplusTools/blob/main/R/plot_nhdplus.R#L161 -- in conversation with @paleolimbot it seems like moving away from that will be wise. I really like the simplicity of it. -- it's just a set of utilities to make a map with base graphics where you can layer your base plot calls on top of an alreaddy initialized map.

It seems like {mapsf} is close to that but implements a fairly different API. Maybe {tmap} is the ticket to stay in base R graphics?

@rCarto
Copy link
Contributor

rCarto commented Dec 17, 2022

Hello,
mapsf creates maps in base graphics. You can combine mf_map() calls with plot(st_geometry()) calls without problems. The theming part of the package sets specific margins and default colours, and that's what is used by mf_map() and other functions. This part could be more explicit in future versions (maybe through the use of options()).
Anyway, I'm open to discussion in order to make the package more reusable.

@dblodgett-usgs
Copy link
Author

Thanks @rCarto -- I think a rudimentary {mapsf} with {maptiles} will probably be the most 1:1 for what I've been doing with {rosm} and {prettymapr}. I'll do a little experimentation and drop a reference to my progress here.

Out of curiosity, what's the design distinction between tmap and mapsf that would help me and others understand why to pursue one or the other?

@paleolimbot
Copy link

Yes, prettymapr will be mothballed soon. The rosm package, because of its use in ggspatial, will be rewritten in the next month or so to remove the rgdal dependency (but all of tmap, mapsf, and maptiles are awesome and you should use them!).

@edzer
Copy link
Member

edzer commented Dec 18, 2022

Out of curiosity, what's the design distinction between tmap and mapsf that would help me and others understand why to pursue one or the other?

tmap, ggplot2 and ggspatial all build on package grid: they incrementally build a plot object, and plot it in the final stage, after which you cannot easily add things to that plot. mapsf (and e.g. sf::plot.sf) use the base plot commands from package base (or graphics), which works with sequential calls to routines that plot things to the graphics device sequentially. Using the latter approach it is easier to customize plots by adding things e.g. by calls to points(), text(), lines(), arrows() and so on, but it is practically impossible to create (good) facet plots using the latter approach. I think that in addition to having a native NA, facet plots are the main reason why R stands out in the data science landscape.

@dblodgett-usgs
Copy link
Author

Perfect. Thanks for that, @edzer

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

No branches or pull requests

5 participants