depreciation of shapefiles #62
Comments
|
I think we'll have to find ways of creating GPKG for:
where several have no known CRS. Then update the help pages to use the GPKG, maybe adding a note that the shapefiles may be withdrawn at a forthcoming release. A similar message might be added to the package startup messages, but that might wait until the release before they were dropped. We'll need to watch the size of the package. |
|
See also: r-spatial/sf#2049 |
|
@Nowosad may I move on this? Should we retain the shapefiles or replace them? Should I try to instrument revdeps? |
|
@rsbivand yes, please! I think we should aim for removing the shapefiles and replacing them with, e.g., gpkgs. Revdeps should be useful to do to check the impact of the change. Also -- I've noticed that shapefiles are used quite a lot in docs of sf (see https://github.com/r-spatial/sf/blob/main/R/read.R and https://github.com/r-spatial/sf/tree/main/inst/shape). Do you think it would be worthwhile also to depreciate shapefiles there? |
|
Re. |
|
@Nowosad GPKG created for all shapefiles but I suggest submitting this soon, passes |
|
The possible "most" dependent packages were: "apsimx" us_states but of these only the following (plus GWnnegPCA above) had hits on so: bispdep: shapes/columbus.shp I'll add issues here as I raise them, or dates of emails sent. None appear to need the shapefile representation. |
The original reason for that was that at the time of first submission, certain CRAN platforms did not have sqlite linked to gdal, and could not read gpkg. It could well be that this no longer is the case. |
|
|
@Nowosad |
|
@rsbivand as it is September already -- should I submit the current version of spData to CRAN now? |
|
I'll check tomorrow. Are we going to drop all the shapefiles now? |
|
I think the plan is to put the current version to CRAN as it is, and drop all the shapefiles afterwards. |
|
Ok, submit as main is now, then I'll make a PR to drop the shapefiles. |
|
@Nowosad Please wait, I need to check the validity of shapes/NY8_bna_utm18.gpkg and shapes/NY8_utm18.gpkg. |
|
One additional issue, @rsbivand: |
|
Will update this shortly - Jim LeSage has retired and the DNS subscription has I think lapsed. I'm dropping the URL markup - if anyone needs the original, it may be found in the wayback machine: https://web.archive.org/web/20160416132456fw_/http://www.spatial-econometrics.com/html/jplv7.zip |
|
|
I saw mention of reading from .zip with GDAL 3.7.0, so here's a quick note on support that's older. it works in gdal 3.4.3 when using the actual virtual file protocols no need even to download Rscript -e 'sf::read_sf("/vsizip//vsicurl/https://github.com/user-attachments/files/16865728/GB_election_2024_sim.gpkg.zip",
query = "SELECT * FROM GB_election_2024_sim LIMIT 1")'
Simple feature collection with 1 feature and 19 fields
Geometry type: POLYGON
... |
|
Hi @rsbivand -- what do you think of removing .shp files soon and then submitting a new package version to CRAN? |
|
I'll take a look tomorrow, run revdeps, and try to raise issues. |
|
Currently GWnnegPCA (emails starting 8 June, no response), sphet (issue and PR, will follow up gpiras/sphet#20), and my packages spdep r-spatial/spdep#174 and spatialreg r-spatial/spatialreg#58 are fixed but fixes not merged - will merge. #72 created. |
@rsbivand As we discussed last month, several shapefiles exist in the package (https://github.com/Nowosad/spData/tree/master/inst/shapes), that we may consider depreciating. However, I do not know how to do it properly (the depreciation process in R is fairly well documented for functions, but not for external data). Do you know how to do it best?
The text was updated successfully, but these errors were encountered: