#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
Keywords: v.import where | CPU: Unspecified
Platform: Unspecified |
----------------------------+-------------------------
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.
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.
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
it.
Actually, the where option is thus not available at all in the GUI import
wizard...
Once again a case where I think that dumbing down the GUI is not always a
good idea.
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
it.
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).
Any reason why the menu entry for v.in.ogr is "Common import formats"
while for r.in.gdal it is "Common formats import"?
>
> Actually, the where option is thus not available at all in the GUI
import wizard...
>
> Once again a case where I think that dumbing down the GUI is not always
a good idea.
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
it.
>
> 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. 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.
>
> Any reason why the menu entry for v.in.ogr is "Common import formats"
while for r.in.gdal it is "Common formats import"?
>
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
it.
> >
> > 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
import.
Replying to [comment:5 mmetz]:
> Replying to [comment:4 mlennert]:
[...]
> >
> > 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
import.
The menu entries have been changed in trunk r71108. The [r|v].import
modules are now labelled as "Simplified [raster|vector] import with
reprojection" and use the customized GUI interface. r.in.gdal and v.in.ogr
use their generic UI interface and are in the wxGUI menu labelled as
"Import of common [raster|vector] formats".
