Major overhaul to get CRAN-ready

[hafen]

This looks a bit lengthy, but in all not much of substance was changed in the package. There are no breaking changes - previous code should still run just fine. Please let me know what you think about the questions raised.

Overview of changes:

• Running devtools::check() now runs with no issues, due to the updates below.
• In DESCRIPTION, add "Lars Simon Zehnder" as a contributor and noted that the contribution was for Munkres' Assignment Algorithm.
• Add URL and BugReports to DESCRIPTION.
• Update version to 0.1.0.
• Add NEWS.md.
• Add .travis.yml for automatic testing (note that you will need to go here to turn on Travis testing: https://travis-ci.org/sassalley/hexmapr).
• Rename 2013-09-24-minimal-assignment.cpp to minimal-assignment.cpp
• Add ".Rbuildignore" file.
• Add ".lintr" file.
• Document R and Rcpp code using roxygen2
• Remove all unneeded dependencies and move needed dependencies to imports and handle appropriately in code.
• There were docs for a function "gridify" that didn't exist in the R code so it was removed.
• The list returned by calculate_cell_size() is now of class "geogrid".
• Added plot method for object of class "geogrid".
• In calculate_cell_size() made learning_rate have default of 0.03. Is this a good default? If not, what would be a good default?
• In calculate_cell_size() made seed default to NULL, in which case seed isn't explicitly set.
• In calculate_cell_size(), made shape_details default to NULL, in which case it will be automatically computed by calling get_shape_details() on the provided shape argument.
• Note: In general I have removed get_shape_details() from the examples. Since it only seems to be used inside of calculate_cell_size() and since it appears to be very fast to compute, it seems fine to have the default behavior to be that get_shape_details() is not needed to be called directly by the user but only as-needed inside calculate_cell_size(). If there is never need for the result of get_shape_details() outside of being used inside calculate_cell_size(), I'd even argue that we go a step further and not export get_shape_details() and remove the option to supply shape_details as an argument to calculate_cell_size().
• Add verbose argument to calculate_cell_size() to allow user to specify whether messages should be printed while the algorithm iterates.
• Change print() to message() in calculate_cell_size().
• Update README.Rmd to reflect all of these changes and re-render README.md.
• Added some simple tests (more should be added).
• Add lintr test.
• Slightly modify some of the R code to pass lintr tests.
• Add support for codecov.io badge (code test coverage is now 95%). Will need Travis enabled for this to work.
• Add CRAN, Travis, and code coverage badges to README.Rmd.

Questions:

• Should calculate_cell_size() have a different name? like calculate_grid()? The name calculate_cell_size() makes one think that you are getting a cell size back instead of a grid.
• Should the package have a different name? "hexmapr" may give the impression that the package makes hex map plots, which I suppose it does provide the sp objects for. Also, the package is for regular grids as well. Maybe something like geogrid or if geo is too specific since it works for any polygons, maybe something else? This is only a suggestion.
• In DESCRIPTION, it says "assigns the content of the existing polygons to the new grid in three different ways". Should this be two ways (regular and hexagon)? The three assignment algorithms are also mentioned in assign_polygons().

[sassalley]

Hi @hafen

Thanks for submitting such a fantastic PR. It is thorough and very clear. Please see below for responses to the questions.

1. Yes - I think calculate_cell_size() should be renamed and the recommendation of calculate_grid() should be adopted. The current name is a bit of a hangover from what's happening underneath but this is not relevant to the user.
2. Interesting question - in the early stages I was motivated by the generation of Hexmaps but decided to add in the regular grids given that it was a reasonably simple feature. Given that the (likely) main use if for the generation of maps, I think geogrid works. I will crowd-source some more opinions and respond further as soon as possible.
3. Ah - this should be removed. Initially, the package assigned polygons to the new grid using algorithms (two) other than the Munkres. I decided to remove them since neither algorithm was as effective at mimicking the original geography. Technically it should be "assigns the content of the existing polygons to the new grid using the Hungarian algorithm"

Questions raised in the body of the PR

• _In calculate_cell_size() made learningrate have default of 0.03. Is this a good default? For now yes. I need to investigate the impact of this on different sized grids but recommend 0.03 for ~ 4 - 80 geographic units (e.g. states) (potentially lower for greater numbers of units).
• _I'd even argue that we go a step further and not export get_shape_details() and remove the option to supply shape_details as an argument to calculate_cellsize(). Agreed this is also a good idea.

A few questions in response if i may:

• How would you recommend changing the name of the package? Just change it in the documentation (etc...) or should we also rename the repo?
• Given your overhaul, is it not fair to include yourself as a key contributor?

[hafen]

This all sounds great. I just updated my fork to change calculate_cell_size() to calculate_grid() throughout, clarified about the use of the Hungarian algorithm, and added myself as a contributor. I also un-exported get_shape_details() and removed that as an argument to calculate_cell_size() (it's now just called inside that function, saving the user a step).

Given the function name change, these changes are breaking from prior usage and examples, so I also kept the old functions calculate_cell_size() and get_shape_details () which now just display a hard deprecation error and point users to the new functions. Hopefully that is sufficient to get existing users oriented to the changes.

The only outstanding thing is the package name. If you change it, I'd suggest renaming the github repo as well (you can do this without losing your forks / stars, and the old link will redirect to the new one). This is a major change since people already know it by this name, and because of that I was hesitant to suggest it. I'll leave it entirely up to you. The reason I bring it up now is it's easier to change now than when it's on CRAN and more people are using it.