Comments (9)
What you say makes sense given your assumptions, but your assumptions are incorrect.
-
Using
sf
methods for base functions like subsetting with[]
does not require thatsf
is on the search list.sf
just needs to be loaded, and then R will automatically dispatch to the methods. -
You don't check if
sf
is loaded, you check if it is on the search list. A check for whether it is loaded is"sf" %in% loadedNamespaces()
. But usingrequireNamespace()
does this check for you. -
requireNamespace()
is designed specifically for the case where you have a conditional dependency on a package. Normally you would listsf
inSuggests:
, and then test for it before each use. But it is acceptable to continue ifsf
isn't present, provided you can handle that case (which you can).
So what I'm suggesting you do is to make sure sf
is in Suggests:
, then try to load it using requireNamespace
each time you create an object inheriting from "sf"
. If the load fails, then give the user a warning and continue on as now.
One possibility that this doesn't handle is a user who has sf
installed, but for some reason doesn't want to load it. That could also be handled, but I don't really see the point. It's a pretty dangerous approach, since all those sf
methods won't be found, and the generics will do the wrong thing. But if you want to allow this behaviour, it would be possible, you'd just need to work out the API to ask for it.
from osmplotr.
An example of sf
's conditional dependence on dplyr
, using this mechanism, is found here.
from osmplotr.
Yeah, thanks, you're right. I implemented a similar warning in osmdata
, but did not propagate it through to osmplotr
- shall now do!
from osmplotr.
I'm not sure the warning in osmdata
is working if this is on the master branch. I just started a new session, installed it, and ran
library(osmdata)
hampi_sf <- opq ("hampi india") %>%
add_osm_feature (key="historic", value="ruins") %>%
osmdata_sf ()
methods(class = "sf")
This produces a message that no methods are defined. However, we have
> class(hampi_sf$osm_points)
[1] "sf" "data.frame"
so there is an "sf"
object in there. If I manually run requireNamespace("sf")
it returns TRUE
, and afterwards there are lots of methods for the class:
> methods(class = "sf")
[1] [ [[<- $<- aggregate as.data.frame cbind coerce identify initialize
[10] merge plot print rbind show slotsFromS3
see '?methods' for accessing help and source code
from osmplotr.
It's only used, and only necessary, with trim_osmdata()
, and uses this function (noting that requireNamespace
only confirms that a package is installed, but what we need to is to check whether it's namespace has been loaded, and that requires the code shown there). I just need to copy that over to osmplotr
and employ it in appropriate place.
from osmplotr.
I think you are misunderstanding the R internals. When you call requireNamespace("sf")
, that checks if it's loaded and if not attempts to load it, and returns TRUE
if it is loaded at the end. FALSE
indicates it is not loaded and the load attempt was unsuccessful, typically because the package is not installed, but there can be other reasons for it to fail.
Your is_sf_loaded
function tests something different: it tests whether the package is on the search list, i.e. loaded and attached. That means that users can call methods from sf
without any sf::
prefix.
In order for class "sf"
methods to work, you only need the package loaded, not attached.
It may be that trim_osmdata
needs sf
on the search list. I'd recommend against requiring that, but that's up to you. (You can avoid putting it on the search list and use the sf::
prefix on every function you call from it.)
However, the issue that I reported is to fix problems for other users: since osmplotr::extract_osm_objects
and osmdata::osmdata_sf
return objects that contain things with the "sf"
class, your users should expect them to work properly, and should be warned if they won't. They'll only work properly if sf
is loaded, and that's what requireNamespace("sf")
attempts to achieve.
from osmplotr.
Sorry for any confusion in my previous response. I understand your point and agree with it in principle, but what I should have mentioned was that both osmplotr
and osmdata
are intended to function without sf
dependency (osmdata
merely Suggests: sf
, osmplotr
not at all). This is a strict principle because an sf
dependency is a huge thing, and there are always cases in which / people for whom this is too burdensome. These packages are as lightweight as possible, and so internalize their own versions of much sf
functionality. (And a lot of the tests in both cases ensure ongoing compliance with current versions of sf
.)
This is why there can be no requireNamespace
calls, but only checks to see whether sf
is loaded, because things like sf
subset calls only work within other packages with sf
loaded (in turn because CRAN forbids explicit namespace addressing of internal functions - no :::
). That means in this case that there is nothing that can be done about this problem, nor as far as I can see it at present is there actually any way to issue an appropriate message, because the subsetting operation is an sf
operation and not at all related to any direct osmplotr
functionality. Does this make sense?
from osmplotr.
For completeness: see also r-spatial/sf#970
from osmplotr.
Thanks @brry, @dmurdoch, @edzer - i agree that a package that produces sf
objects should do it's best to ensure that sf
methods work, so now have a packageStartupMessage
if !requireNamespace (sf)
:
#> NOTE: 'sf' package must be loaded for 'sf' methods to work
from osmplotr.
Related Issues (20)
- ggplot geoms HOT 1
- finish line2poly function and vignette HOT 1
- using sf operations HOT 2
- osm_line2poly limitations
- use vcr to mock tests HOT 1
- Repo topics to review HOT 2
- Error with print_osm_map HOT 5
- How to use the maps in RMarkdown HOT 2
- Licence HOT 4
- fix vignette
- sf geometry class warning HOT 1
- if(nrow(NULL)==0) error in extract_osm_objects HOT 1
- geom_to_xy has no definition for multilinestring HOT 1
- figs not rendering on docs.ropensci HOT 3
- upgrade to new spatstat packages HOT 2
- Fix pkgdown configuration for reference HOT 3
- Question HOT 2
- Archived on CRAN HOT 4
- Action needed before 2023-01-25: update osmplotr's dependencies as it cannot be built HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from osmplotr.