[GRASS-dev] [GRASS GIS] #3349: v.import: add 'where' parameter
trac at osgeo.org
Mon May 22 05:58:10 PDT 2017
#3349: v.import: add 'where' parameter
Reporter: mlennert | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.4.0
Component: Vector | Version: unspecified
Resolution: | Keywords: v.import where
CPU: Unspecified | Platform: Unspecified
Comment (by mmetz):
Replying to [comment:4 mlennert]:
> Replying to [comment:3 mmetz]:
> > Replying to [comment:2 mlennert]:
> > > Replying to [comment:1 mmetz]:
> > > > Replying to [ticket:3349 mlennert]:
> > > > > Was there choice of not adding a 'where' parameter to v.import a
deliberate one ? I would find this parameter quite useful, but do not want
to implement it if there was an explicit decision against it.
> > > >
> > > > The reason to not add a 'where' option to v.import, as well as
various other options and flags present in v.in.ogr but not in v.import,
was to provide a module with a simplified user-interface that combines
v.in.ogr + v.proj. It was not meant to be a replacement for using v.in.ogr
and v.proj separately.
> > >
> > > Well, the fact that AFAICT the GUI now exclusively uses v.import for
imports (even when you chose "Common import formats" and **not** "Import
of common formats with reprojection") and automatically proposes to
reproject data at import if it is not in the location's projection,
creates a situation where most people will use v.import, without knowing
> > When you choose "Common import formats", you get a custom GUI
interface to v.in.ogr, not the interface of v.in.ogr --ui
(gui/wxpython/xml/wxgui_items.xml). That means the 'where' option (and
others) is missing in the custom GUI interface to v.in.ogr. Similar for
r.in.gdal (Import raster data -> Common formats import).
> These custom GUIs now directly call v./r.import.
It seems that wxgui_items.xml has not been updated accordingly.
> The only difference between the first and second menu entries in the
respective GUI menus is that the first calls the GUI wizard (which then
calls v./r.import) and the second calls the v./r.import module GUI.
> If the wizard calls the *.import modules, then I think it would be
better to have as second entry a call to the original v.in.ogr/r.in.gdal
module GUIs in the menu, instead of the v.import GUI which does not bring
much added value in comparison to the wizard...
> This would allow to increase the visibility of the original modules and
their additional options.
Sounds reasonable: v.import + GUI wizard for quick and dirty import,
v.in.ogr + generic UI for full-featured import, accordingly for raster
Ticket URL: <https://trac.osgeo.org/grass/ticket/3349#comment:5>
GRASS GIS <https://grass.osgeo.org>
More information about the grass-dev