r-spatial / rgeopackage Goto Github PK

• Add readme
• Add NEWS.md for 0.1.0
• Add zenodo webhook
• Add zenodo metadata
• Release 0.1.0 on CRAN
• Release 0.1.0 at GitHub
• Add zenodo badge

Since the package may be going to expand substantially (#4), it will be wise to add unit tests as well as automated package checks on different platforms in GH Actions, in order to maintain and guarantee functionality in the future.

Do you agree @elipousson ?

Hi @edzer, it seems I have no access to this repo's settings; I need to change the default branch in GitHub from master to main. Can you do that, or perhaps arrange access to repo settings differently?

Include a vignette that:

• more or less repeats what is in README.md (= absent from installed package)
• includes a simple example using preset_timestamp()

I'd also love to see the verbose parameter used in the timestamp functions be replaced with a quiet parameter for consistency with sf.

Originally posted by @elipousson in #4 (comment)

@edzer it appears that @elipousson is going to boost this package to a level much higher than currently the case 🚀. See #4 and his fork https://github.com/elipousson/rgeopackage.

For that reason, it seems best to add him to r-spatial and/or this repo, at least what is needed so that he can do maintenance/authoring work more easily.

@edzer (or others) is that OK with you and could you handle that? At least I didn't find how I can give him write access to the rgeopackage repo, so that he can make e.g. branches and pull requests inside the repo.

@elipousson please respond if you see things different (but the signs make me add this issue 🙂).

Currently we read about amend_timestamp():

this function is especially useful in the presence of the optional table gpkg_metadata_reference, as GDAL does not control its timestamps as of writing (for GDAL 3.1.3).
See a corresponding issue in the GDAL source repository.

Since quite a while this issue was solved in GDAL. To be checked further and docs updated.

I'm note sure if this is already possible using the layer_options and dataset_options for sf::st_write() but I'm curious if you've explored the possibility of adding support for the GeoPackage schema extension, ideally allowing column labels or a dataframe with definitions/aliases to match column names, to serve as the data to use for the schema. Happy to spend some time figuring this out if you have any pointers on how to approach it!