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: grass-dev@…
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)

in reply to:  description ; comment:1 by mmetz, 5 years ago

Replying to lucadelu:

Hi devs,

v.import is using v.in.ogr but most of v.in.ogr options are missing

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.

in reply to:  1 ; comment:2 by lucadelu, 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

in reply to:  2 comment:3 by mmetz, 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:4 by neteler, 5 years ago

Milestone: 7.8.07.8.1

Ticket retargeted after milestone closed

comment:5 by neteler, 5 years ago

Milestone: 7.8.17.8.2

Ticket retargeted after milestone closed

comment:6 by neteler, 5 years ago

Milestone: 7.8.2

Ticket retargeted after milestone closed

comment:7 by neteler, 5 years ago

Milestone: 7.8.3
Note: See TracTickets for help on using tickets.