Opened 5 years ago
Last modified 5 years ago
#3869 new enhancement
v.import add missing v.in.ogr options
| Reported by: | lucadelu | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | 7.8.3 |
| Component: | Vector | Version: | unspecified |
| Keywords: | v.import options | Cc: | |
| CPU: | Unspecified | Platform: | Unspecified |
Description
Hi devs,
v.import is using v.in.ogr but most of v.in.ogr options are missing, I would like to add them (or at least some of them), the missing options have not been added for some reasons or could I work on it?
Change History (7)
follow-up: 2 comment:1 by , 5 years ago
follow-up: 3 comment:2 by , 5 years ago
Replying to mmetz:
v.import is (was) meant to be an easy to use module with a simple interface for importing vector data. The idea was that if you want more control or more options you can use the more advanced module v.in.ogr.
I fully understand, but my request is for a better user experience. I was at JRC for a meeting about INSPIRE support and I discovered a really useful option to use in gdal_doo to have a better support for GML files. I think it is important to have this capability also in v.import for example
comment:3 by , 5 years ago
Replying to lucadelu:
Replying to mmetz:
v.import is (was) meant to be an easy to use module with a simple interface for importing vector data. The idea was that if you want more control or more options you can use the more advanced module v.in.ogr.
[...] I was at JRC for a meeting about INSPIRE support and I discovered a really useful option to use in gdal_doo to have a better support for GML files. I think it is important to have this capability also in v.import for example
The gdal_doo option is IMHO an advanced option: you need to know to the OGR driver needed to read this dataset, and you need to read the GDAL/OGR documentation for this particular driver to know which dataset open options (or GDAL configuration options) are needed to properly read this particular dataset.
Thinking about it, it is ok to provide all options of v.in.ogr and v.proj also in v.import, as long as they go into separate gui sections, something like "advanced".
Maybe there should be a gui section "dangerous" for the v.in.ogr -o flag and the v.import options epsg and datum_trans.
Considering the substantial changes in PROJ 6+, it might no longer be possible to do fully automated reprojection, instead users need in some cases select the appropriate reprojection method for their particular data: there can be several methods available to transform coordinates from one CRS to another CRS, users have to decide which one to use. Just as a warning that v.import might not work as expected with proj 6+ and gdal 3+ in future releases of GRASS GIS.
comment:7 by , 5 years ago
| Milestone: | → 7.8.3 |
|---|
Replying to lucadelu:
v.import is (was) meant to be an easy to use module with a simple interface for importing vector data. The idea was that if you want more control or more options you can use the more advanced module v.in.ogr.