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.

Sign up for GitHub

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

Jump to bottom

Support for writing a non-spatial table to a GeoPackage #1345

Closed
florisvdh opened this issue Apr 7, 2020 · 2 comments
Closed

Support for writing a non-spatial table to a GeoPackage #1345

florisvdh opened this issue Apr 7, 2020 · 2 comments

Comments

@florisvdh
Copy link
Member

In its layer options, GDAL's GPKG-vector driver offers the possibility to store non-spatial attribute tables (~dataframes), using the option ASPATIAL_VARIANT. However it seems that st_write() does not support this:

st_write(nonspatial_df,
         "existing_gpkg.gpkg"), 
         layer = "nonspatial_table1",
         driver = "GPKG",
         layer_options = "ASPATIAL_VARIANT=GPKG_ATTRIBUTES")

This throws an error:

Error in st_sf(x, ..., agr = agr, sf_column_name = sf_column_name) : 
  no simple features geometry column present

Is there an alternative to properly use this GDAL feature from R, or else could it be incorporated in st_write()?

An alternative is to manually insert the table with RSQLite::dbWriteTable(), which does work with st_read() afterwards - probably because GDAL lists all non-spatial tables even when they were not registered in any GeoPackage system tables. However this approach of writing violates the GPKG standard, which e.g. requires registration of tables in the gpkg_contents table.
florisvdh added a commit to inbo/n2khab-preprocessing that referenced this issue Apr 8, 2020
@florisvdh
generate_soilmap_simple: register non-spatial table *
d231436 
Non-spatial tables need to be registered in the GeoPackage
in order to conform to the GPKG standard.
For now, this is done in a manual fashion, despite the ability
of GDAL to take care of this for GPKG. I found no way to use
this ability from R, so implemented the easy, though obsoleted
approach of GeoPackage 1.0 to register non-spatial tables as
data_type "aspatial" in the gpkg_contents table; see:
https://gdal.org/drivers/vector/aspatial.html#vector-aspatial

Question on implementation in R, see:
r-spatial/sf#1345

The current way (GPKG 1.2) to handle this (data_type "attributes")
is supported by GDAL, see:
https://gdal.org/drivers/vector/gpkg.html#layer-creation-options .
But it needs more work to do it manually, so
made a GPKG 1.0 compliant version for now.
See https://www.ogc.org/standards/geopackage .

Note that GDAL is supportive when reading non-compliant
gpkg-files, as it 'will also, by default, list non spatial tables
that are not registered', which is why this worked beforehand
with st_read().
See https://gdal.org/drivers/vector/gpkg.html#non-spatial-tables .
@edzer
Copy link
Member

edzer commented Apr 11, 2020 •
edited
Loading

Incorporating this in st_write would be possible.

edzer added a commit that referenced this issue May 16, 2020
@edzer
support writing aspatial tables with st_write()
bbf95cf 
addresses #1345
@edzer edzer mentioned this issue May 16, 2020
Merged
@edzer
Copy link
Member

edzer commented May 20, 2020

Closed by #1396.

@edzer edzer closed this as completed May 20, 2020
edzer added a commit that referenced this issue Jul 7, 2020
@edzer
write_sf() is no longer silent under GDAL 3.1.1; #1345
b124fe5
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@edzer @florisvdh