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

considerable speedup #282

Closed
wants to merge 3 commits into from
Closed

considerable speedup #282

wants to merge 3 commits into from

Conversation

adokter
Copy link
Owner

@adokter adokter commented Oct 25, 2019

Continuing #278 in a branch native to this repository

@adokter adokter changed the title considerable speedup (cont.) considerable speedup Oct 25, 2019
@adokter adokter mentioned this pull request Oct 25, 2019
Copy link
Owner Author

@adokter adokter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @bart1 I've added some more comments / questions. I think part of my confusion is that I'm not 100% confident on how you use the raster inputs, also in scan_to_spatial and integrate_to_ppi (see #281), examples with the function will clarify a lot probably.

sep = ""
))
values(res)<-1
spdf <- (spTransform(rasterToPoints(res,spatial=T), localCrs))
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is currently the only use of scan_to_spdf(). Here you take your input raster, convert it to a spdf, and transform it to an aeqd projection (spdf <- (spTransform(rasterToPoints(res,spatial=T), localCrs))). Wouldn't it be more user-friendly if the new scan_to_spdf() takes this raster and CRS as inputs (instead of an spdf that isn't very well defined as input)? Function structure would then be more similar as scan_to_raster().

Also: note that rasterToPoints() throws out any raster points with NA values, is that the desired behaviour? If so, please explain in documentation what kind of values should be in the input raster of the res argument.

Comment on lines +190 to +199
#' convert a polar scan into a raster
#'
#' convert an object of class 'scan' into a raster of class 'RasterBrick'
#' @inheritParams scan_to_raster
#' @param spdf an input object of class SpatialPointsDataFrame
#' @return an object of class SpatialPointsDataFrame. FIXME: not clear what kind of spdf is expected here
#' @details FIXME: to be added
#' @export
#' @examples
#' FIXME: to be added
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add roxygen header with title, description, details, and example

#' @details FIXME: to be added
#' @export
#' @examples
#' FIXME: to be added
scan_to_spdf <- function(scan, spdf, param, lat, lon, k = 4 / 3, re = 6378, rp = 6357) {
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's think of a better name that makes clear you are projecting onto something that you provide as input, not simply a one-to-one conversion of a scan to a spatialpointsdataframe (which is what scan_to_spatial() does)

@adokter
Copy link
Owner Author

adokter commented Feb 3, 2020

moved to issue #293

@adokter adokter closed this Feb 3, 2020
@adokter adokter deleted the bart1-gridSpeedup branch April 9, 2020 15:40
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

Successfully merging this pull request may close these issues.

1 participant