Convert objects to sp and any other for easy use of spatial analysis pkgs

[sckott]

No description provided.

[emhart]

@sckott Thoughts on the best approach here? Do we want to add an extra slot for spatial classes? Have a function that just converts the object and returns a spatial object? Something I haven't thought of?

[sckott]

We do have some conversion in place already, see examples https://github.com/ropensci/spocc/blob/master/R/classes.r#L157-L167

Hmm. Don't know best answer, but IMHO it makes sense to just convert after getting the data back to other classes. I think always just have point data, not polygons or lines. So there are a few relevant sp classes for point data, including SpatialPointsDataFrame and SpatialPoints.

I wonder if we can convert data to polygons or lines from points? Is that a common use case?

We should ask someone working on sp, rgeos, etc. about this

Or maybe @karthik or @cboettig have a good sense for what classes we want to be able to convert to from the data gathered in this package?

[karthik]

Let's wait on the class issue. As Scott says there is more to discuss on this.

[emhart]

Not a very common use case I'd think. So the basic idea would be to code a function that converts a spocc object to a spatial object. Seems like the low hanging fruit here.

[sckott]

Hi @spacedman - This package spocc aims to be a general interface to species occurrence data on the web. Functions in spocc gather data from different web APIs and output an S4 object. We want to build in conversions to objects that people are used to working with in the context of sp, rgeos, rgdal, etc. packages. All data we get is point, so no lines or polygons.

We started doing some simple conversion to a SpatialPointsDataFrame object (see https://github.com/ropensci/spocc/blob/master/R/classes.r#L151-L180). What else should we do? What are the common use cases that we should cover?

[spacedman]

On 4 December 2013 23:49, Scott Chamberlain notifications@github.comwrote:

Hi @spacedman https://github.com/spacedman - This package spocc aims to
be a general interface to species occurrence data on the web. Functions in
spocc gather data from different web APIs and output an S4 object. We
want to build in conversions to objects that people are used to working
with in the context of sp, rgeos, rgdal, etc. packages. All data we get
is point, so no lines or polygons.

We started doing some simple conversion to a SpatialPointsDataFrameobject (see
https://github.com/ropensci/spocc/blob/master/R/classes.r#L151-L180).
What else should we do? What are the common use cases that we should cover

Just having a quick play there, and the example in the docstring doesn't
work:

dat <- occ(query='Accipiter striatus', from='gbif')
spdat <- as(dat, "SpatialPointsDataFrame")
Error in asMethod(object) :
no slot of name "data" for this object of class "occDat"

but I think its because the occ object has an @gbif slot that has the @DaTa
slot:

str(dat@gbif@data)
'data.frame': 20 obs. of 5 variables:
$ name : chr "Accipiter striatus Vieillot, 1808" "Accipiter striatus
Vieillot, 1808" "Accipiter striatus Vieillot, 1808" "Accipiter striatus
Vieillot, 1808" ...
$ key : num 7.73e+08 7.69e+08 7.73e+08 7.73e+08 7.73e+08 ...

maybe you've refactored this or I've got an old version of something
somewhere...

Anyway... something the code doesn't consider is the coordinate reference
system. I see you rely on getting latitude and longitude but there's
various standard lat-long systems that are broadly incompatible. The usual,
modern lat-long system is based on the WGS84 definition of the shape of the
earth, and a particular prime meridian and so on, and is known as EPSG
4326. You can specify that a spatial points data frame is using these
coordinates by doing:

proj4string(foo) = CRS("+init=epsg:4326")

Now some of your species data might be old, and using a different
coordinate system, and if you can't pull that definition from the database
then your coordinates will be a bit off. Possibly a km here and there
doesn't matter on a global scale (do your data sources have
uncertainty/precision measures in their metadata?) but its something you
want to get right if you can.

Barry

[sckott]

Hey @spacedman Sorry about the error. I have just fixed that and pushed in the most recent commit. There was some refactoring and I forgot to fix those as functions.

Yes, the data is WGS84, see GBIF's docs here. Thanks for pointing this out, we'll fix right away.

Any other advice?

[spacedman]

Nothing else to say at the moment! Glad to be of help.

Barry

On 5 December 2013 16:14, Scott Chamberlain notifications@github.comwrote:

Hey @spacedman https://github.com/spacedman Sorry about the error. I
have just fixed that and pushed in the most recent commit. There was some
refactoring and I forgot to fix those as functions.

Yes, the data is WGS84, see GBIF's docs herehttp://www.gbif.org/developer/occurrence#p_latitude.
Thanks for pointing this out, we'll fix right away.

Anything other advice?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-29911185
.

[sckott]

Thanks for the help!